Editorial Policy

Where a manufacturer publishes documentation for a device, that documentation decides the meaning of a code. Support-centre articles are used where no manual section exists. Nothing is published from thin air.

Language models are used for non-factual chores: normalising imported rows, suggesting internal links, spotting likely duplicates, drafting a first summary of a document an editor has already read. They cannot independently establish what a code means.

A page whose content came from a draft is labelled as a draft inside the admin panel until an editor links it to a source. Draft versus verified is a visible internal state, not a formality.

Before a record is marked verified, an editor confirms: the code text as displayed, the device scope it was confirmed for, the severity, and whether any user-level action is safe. If a statement cannot be confirmed, it is removed rather than softened into vagueness.

Every fault page and symptom guide carries a correction form. Reports are stored with the page address and code, reviewed by an editor, and either applied, answered or rejected with a reason.

Owner reports and forum experience can explain how a fault behaves in the field. They are labelled as community context and are never presented as manufacturer documentation, and they never override it.

No “ultimate guides”, no invented statistics, no fake expertise, no filler introductions. A fault page answers first and explains second.