How we decide what to publish
Methodology
The point of this project is that you can tell a manufacturer spec apart from forum folklore without trusting us. Three rules make that possible.
1 — Every fact carries where it came from
Each published value is tagged with its provenance: manufacturer data (OEM), a technical bulletin (TSB), something DMS instrumented (MEASURED), a resolved case with evidence (VERIFIED_CASE), a named technician's experience (EXPERT), or community report (COMMUNITY). A fact with no provenance is not a fact we publish. Aggregates stay unpublished until at least three observations back them.
2 — Observation is not diagnosis
The analyser may say "actual boost stayed 0.51 bar under request and had not closed the gap by the end of the pull." It may not say "boost leak." Naming a cause needs a hypothesis, and a hypothesis needs supporting evidence. This is enforced in the engine, not left to good intentions.
3 — Technical review and workshop sign-off are different claims
A technical review checks the knowledge model — is the code defined correctly, is the diagnostic order sound, does the wording claim more than the evidence allows. A capable model can do that, and we record it as machine-performed rather than put a person's name on work they did not do. A workshop sign-off is a tuner putting their name to an ordering a customer will act on. Only a person can carry that, so pages without one say so.
4 — The order is the product
Anyone can list "possible causes." That list is exactly why people replace parts blindly. The value here is the order to check things in, branched by boost-control architecture, so the cheap test that clears a whole branch comes before the expensive part that usually is not the cause.
What is missing, said out loud: most pages carry a technical review but no workshop sign-off yet, the code coverage is a focused cluster rather than every OBD-II code, and the published case uses synthetic samples and is labelled as such. We would rather show the gaps than paper over them.