Troubleshooting Guide Quality Rubric

Purpose

This rubric defines the target standard for every troubleshooting guide in the library. It is intended for maintenance, review, and future expansion work so new guides do not drift back toward short placeholder-style content.

Minimum structural standard

Every model guide should include all of these sections:

• ## Machine profile
• ## Service posture
• ## Fast triage
• ## Failure patterns and repair logic
• ## Model-specific notes
• ## Service parts and wear points
• ## Escalate to authorized service when
• ## Sources

The Failure patterns and repair logic section should normally contain:

• ### 1. No power / dead machine
• ### 2. Powers up but no welding output or equivalent process-specific no-output branch
• ### 3. Feed, arc-start, or cut-start problem
• ### 4. Poor arc quality / unstable output
• ### 5. Gas, air, or consumable related faults
• ### 6. Intermittent or heat-related behavior

Plasma-only guides may rename the second and third branches to reflect plasma output, pilot, and transfer behavior as long as the same diagnostic intent is preserved.

Content-depth standard

A strong guide should do all of the following:

• Split external setup faults from true machine faults early.
• Separate process-specific complaints instead of collapsing them into generic "bad output".
• Distinguish installation-power problems from feeder, gun, torch, or clamp problems.
• Call out the model's common accessory-driven failure paths.
• Explain what not to assume.
• Define a clear stop point for field service versus authorized service.
• Tell the technician what baseline setup to prove first.
• Tell the technician what measurement, observation, or behavior should confirm a healthy subsystem.
• Tell the technician how to confirm the repair before the job is closed.
• Tell the technician which exact manual section, local file, parts breakdown, or official video topic to open first for a high-frequency complaint.
• Make parts lookup practical by identifying the likely external assembly, wear item, or official parts path before deeper internal repair.

A guide is too shallow if it:

• only says to "check power, gas, and consumables"
• does not distinguish process branches on a multiprocess unit
• treats all TIG complaints the same without separating gas, remote, tungsten, and settings
• treats all plasma complaints the same without separating air, consumables, clamp, and transfer behavior
• lacks branch-circuit or source-quality discussion on portable or dual-voltage models
• gives no measurement or observation thresholds
• stops at fault isolation without telling the technician how to validate the fix

Comprehensive field-service tier

The current structural standard is the minimum acceptable guide. The target for a truly field-service-grade guide is higher.

When a guide is pushed to the comprehensive tier, it should also include:

• ## Required tools and baseline checks
• ## Expected observations and field measurements
• ## Expected voltage, connector, and signal checkpoints when the source set supports concrete internal checkpoints
• ## Fault-code and control-panel clues
• ## Repair actions and post-repair verification
• ## Parts, wear-item, and accessory map when official parts ecosystems or strong local service notes support it
• ## Diagram, board, and connector callouts when local diagrams, schematics, or photos exist
• ## Serial, generation, and package applicability

Those sections should add practical value, not padding. For example:

• Required tools and baseline checks should define the minimum setup needed to prove the machine before chasing accessories.
• Expected observations and field measurements should give the technician pass/fail signals such as voltage behavior, gas flow, airflow, engine speed, or connector heating expectations.
• Expected voltage, connector, and signal checkpoints should convert strong service notes into quick bench checks: named connectors, expected voltages, jumper or switch states, and what an abnormal reading means diagnostically.
• Fault-code and control-panel clues should explain what a code or state usually means in the field and what false-positive causes to eliminate first.
• Parts, wear-item, and accessory map should help the technician identify the highest-value assemblies to inspect or substitute before jumping to internal failure.
• Parts, wear-item, and accessory map should include official part numbers or official parts-page entry points when that information is publicly available and stable.
• Diagram, board, and connector callouts should tell the technician which local file or schematic to open and why, instead of leaving the diagrams disconnected from the guide.
• Symptom-to-reference lookup should tell the technician which exact workbook tab, PDF, manual section, diagram, parts breakdown, or official video topic is the fastest first reference for a specific complaint.
• Repair actions and post-repair verification should define how to confirm the fix and when a machine still fails despite the apparent correction.
• Serial, generation, and package applicability should stop technicians from mixing different revisions, accessory ecosystems, or bundled-package assumptions.

Technician-first presentation standard

For brand-level indexes and shared brand stacks:

• technician repair resources should be grouped ahead of trainer resources
• repair-first items should include the brand index, reference manifest, fault matrix, service dashboard, measurement references, substitution cards, board opening maps, parts triage, job packets, and bench tests
• trainer resources should be grouped separately so they do not crowd out repair navigation for technicians working a live fault

The library can include rich training support, but the first path a technician sees should still be the repair path.

Model-specific depth expectations

MIG and flux-cored models

Strong guides should address:

• wire-size to tip and roll matching
• liner drag and spool-brake behavior
• gas versus flux-core polarity changes
• work-return quality
• spool-gun or aluminum branch if applicable
• expected feed-path checks and what a healthy bare-wire feed test should look like
• post-repair confirmation on feed stability and arc stability

TIG models

Strong guides should address:

• remote mode versus torch-switch mode
• gas path and torch-front-end sealing
• tungsten contamination and prep
• AC baseline reset for AC/DC machines
• cooler integration if water-cooled or commonly paired
• what a healthy pre-flow, start, and post-flow sequence should look like
• pedal or remote isolation steps and final confirmation after correction

Plasma models

Strong guides should address:

• consumable stack or cartridge family
• pilot versus transfer behavior
• clamp placement on coated work
• air dryness and flow under load
• manual versus CNC or mechanized branch if applicable
• internal compressor behavior on built-in-air models
• expected inlet pressure and pressure-under-flow reasoning where documentation permits
• post-repair cut verification on known test material

Multiprocess models

Strong guides should address:

• process-changeover mistakes
• polarity and lead-position changes
• feature-state resets such as synergic, pulse, or stored weld data
• proof of one healthy process before deeper diagnosis
• separation of shared power-source faults from process-path faults
• process-specific confirmation after the suspected fix so settings drift is not mistaken for a successful repair

Engine-driven models

Strong guides should address:

• governed engine speed
• battery, charging, and start path
• weld-output path versus auxiliary-output path
• fuel and maintenance effects
• feeder or remote package isolation where applicable
• post-repair confirmation under weld load and auxiliary load, not idle-only validation

Brand- and platform-specific refinement targets

When source quality permits, strong guides should include:

• known branded accessory ecosystems such as SmartSYNC, ArcReach, spool-gun families, Magnum gun families, or specific remote-control families
• common UI or stored-state reset behavior for digitally controlled machines
• generation or package nuance if the product family spans multiple configurations
• practical field observations about what technicians most often misdiagnose

Source standard

Each guide should prefer:

• official product page
• official manual or operator documentation
• official parts list or spare-parts reference when available
• official accessory or compatibility reference
• official setup, troubleshooting, or maintenance video when available
• official software, firmware, service-file, or calibration reference for digital platforms when available
• official service or support portal
• a carefully framed supporting field observation only if official information is thin

If source quality is weak, the guide should stay conservative and avoid implying unsupported fault-code detail.

Evidence strength affects source framing, not diagnostic depth. If a model is included in the library, its troubleshooting guide should still be written to the same structural and practical depth standard as stronger-source models, while clearly stating any source limitations in ## Sources or ## Model-specific notes.

Source strength should also not become an excuse to omit baseline checks, expected observations, or repair-verification logic. If exact numbers are not supported, the guide should still explain the diagnostic direction using conservative qualitative observations. If exact numbers are supported, the guide should prefer a checkpoint table over burying those values inside narrative paragraphs.

Repair-enablement reference layer

The model guides should be supported by shared repair references, not treated as isolated documents.

The preferred reference layer now includes:

• official-service-literature-map.md
• technician-intake-and-evidence-capture.md
• post-repair-verification-standard.md
• software-firmware-and-calibration-checklist.md

These references are especially important when a brand has thin public component-level service literature. They let the guide remain repair-useful without overstating unsupported internal detail.

Review standard

A guide should be considered ready when:

• all required sections exist
• the fast triage table is specific enough to narrow the fault tree quickly
• process branches are separated clearly
• accessory-specific failure paths are named where relevant
• escalation boundaries are explicit
• source quality is visible and appropriate for the machine

Priority refinement rule

If further improvement time is limited, prioritize guides in this order:

1. High-volume field models
2. Digitally controlled or feature-rich models where settings drift mimics failure
3. Plasma and multiprocess units with multiple subsystem boundaries
4. Industrial packages with feeder, cooler, or mechanized integration
5. Legacy machines with thin official source support