Skip to content
Glitchive

Method

Methodology

A case earns its place in the library when a real AI failure has enough citable evidence to be documented without invention.

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.

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.

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

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.