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.
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:
High-volume field models
Digitally controlled or feature-rich models where settings drift mimics failure
Plasma and multiprocess units with multiple subsystem boundaries
Industrial packages with feeder, cooler, or mechanized integration