Methodology

The sourcing floor

Every case starts with at least one real, citable source. Synthetic cases are never published. Sources are recorded with a title, URL, and source type, then shown on the case file so the evidence remains visible alongside the editorial account.

Submitted leads enter the same method

A case submission is a lead or tip, not a draft. AFL Editorial researches and writes the case file, and the submitted incident must meet the same sourcing floor as any other case. A real incident without a citable public trace does not become a published case.

Verification classes

Every case is labelled with how it was verified. The class is a statement about the evidence, not a ranking of how severe or important the failure was.

• Court-verified — Established through court records or legal filings.
• Public postmortem — The organisation published its own account.
• Vendor-confirmed — The organisation acknowledged the failure without publishing an account of it.
• Incident database — Recorded in a recognised incident database.
• GitHub trail — Reconstructed from issues, commits, and maintainer discussion.
• First-hand account — Reported directly by someone involved, with corroborating detail.

How a case is structured

The order is fixed because it follows the sequence a practitioner debugging the same symptom needs: what happened, what signals to search for, what mechanism caused it, and what to do differently next time.

1. Overview — what happened
2. Context — the system, what was being built, and the expected result
3. What failed — the observed behaviour
4. Symptoms — searchable signals, phrased the way practitioners actually search
5. Root cause — the real mechanism
6. Technical explanation
7. Contributing factors
8. Attempted fixes — what was tried and did not work
9. Lessons learned
10. Prevention checklist — actionable items
11. References — the cited sources

How a solution is structured

A published solution identifies the aspect of the root cause it addresses, explains the fix at mini-postmortem depth, describes how to prevent recurrence, and states its tradeoffs, including when it is the wrong choice. Tradeoffs are mandatory; a solution without them is not publishable.

When the record is silent

Contributing factors and attempted fixes may be recorded as Not publicly documented when the public record is genuinely silent. That wording keeps a thin but real incident from being padded into something it is not. Padding a case is a failure of the method, not a stylistic choice.

What we don’t publish

Glitchive does not publish hypotheticals, reconstructions with no citable trace, or accounts that amount to naming individuals for blame. The library documents systems and mechanisms so practitioners can learn from them.

Corrections

Corrections are part of the record. See the corrections page for what can be corrected and how changes are recorded.