Editorial Policy

Publication standard

A public fault record must contain a brand, product scope, displayed code, source description, public source URL, source-check date, applicability statement, safety boundary and correction path. Missing evidence blocks a record from being treated as verified.

Evidence levels

1. Manufacturer manuals, service bulletins and official support databases are preferred.
2. Authorized service material may supplement a manufacturer record when its scope is clear.
3. Regulatory and standards material supports general safety rules, not brand-specific code meanings.
4. Repair sites, forums and videos may identify a research lead but do not independently support hazardous work.

Applicability

Codes can change by model, production year, controller and firmware. When the dataset does not contain that scope, the page says so. Editors must not turn a product-family match into an all-model claim.

Safety and repair language

Component names are descriptions, not confirmed failed parts. The site avoids instructions for live electrical work, interlock bypasses, fuel or refrigerant opening, pressure release, guarded moving machinery and other hazardous-energy work. See the safety framework.

AI-assisted work

Automation may normalize fields, create consistent page structure and identify missing data. It may not invent meanings, models, sources, safety status, credentials, test results or repair outcomes. Bulk changes must pass the repository validator and production build.

Updates and corrections

Visible dates distinguish source-check timing from page modification. Corrections should include the exact model, controller, displayed code and a public source where possible. Material errors are corrected in the source record and regenerated across all affected pages.