Absence receipt
What failed when the key person was removed from the task?
FIELD MANUAL
The Six Fires
A Ministry diagnostic framework for testing Absence, Outage, Scarcity, Error, Capture, and Exclusion without pretending the framework is a scientific taxonomy.
QUICK ANSWER
In one sentence
A Ministry diagnostic framework for testing Absence, Outage, Scarcity, Error, Capture, and Exclusion without pretending the framework is a scientific taxonomy.
THE CONTROLLING CLAIM
DO NOT ASK WHETHER THE SYSTEM LOOKS RESILIENT. LIGHT THE FAILURE TEST AND SEE WHAT STILL WORKS.
Systems look strongest while nothing is missing. The founder answers. The vendor is online. The source is available. The correction has not yet arrived. Everyone can enter because the people excluded are not in the room. Resilience becomes visible only when something ordinary is taken away and the work is forced to reveal what it depended on.
TRUTH BOUNDARY
The Six Fires are a Ministry diagnostic framework. They are not an established scientific taxonomy and no cited source empirically validates the six-part scheme as a whole. External sources support particular component concerns—continuity, accessibility, correction, portability, governance, and preservation—not the framework’s universal correctness.
NIST SP 800-34 Rev. 1 is cited here through NIST’s updated Final 11/11/2010 record. NIST separately marks the earlier 05/31/2010 Rev. 1 record withdrawn because the updated record superseded it. This citation does not validate the Six Fires taxonomy.
FIRE 01 — ABSENCE
Can the work continue without its founder?
Material example: the only person who knows how to publish, verify, or correct the project becomes unavailable.
Failure test: hand a bounded task to another person with the existing documentation and observe where they must guess.
Does not prove: successful handoff of one task does not prove the entire institution is succession-ready.
FIRE 02 — OUTAGE
Can the work continue when a primary platform fails?
Material example: the hosting account or collaboration platform is unavailable while the underlying public files still exist.
Failure test: identify the canonical files, offline copies, dependencies, and written restore path; rehearse a non-destructive reconstruction in a local environment.
Does not prove: a local reconstruction does not guarantee domain, mail, DNS, or vendor continuity.
FIRE 03 — SCARCITY
Can the system describe honest alternatives when a dependency disappears?
Material example: a free service becomes paid, a volunteer leaves, a tool becomes unavailable, or a material resource is temporarily scarce.
Failure test: name the dependency, its substitute paths, the degradation each substitute causes, and the point at which the service should pause rather than fake capability.
Does not prove: listing alternatives does not mean they are affordable, lawful, accessible, or equally effective.
FIRE 04 — ERROR
Can a correction reach the copies that depended on the broken claim?
Material example: a Source ID is corrected or a published factual statement changes after several pages already cite it.
Failure test: use the Source Ledger to locate dependents, classify reliance as essential/supporting/contextual/redundant, review the affected claims, and record propagation.
Does not prove: source change does not automatically invalidate every dependent conclusion.
FIRE 05 — CAPTURE
Can participants challenge, repair, appeal, fork, or leave where the system permits?
Material example: one platform, leader, vendor, or procedure becomes the only practical route to participate.
Failure test: run the Exit and Human Agency questions—notice, challenge, correction, portability, alternatives, appeal, and continuity.
Does not prove: every dependency is illegitimate or every organization can provide costless Exit.
FIRE 06 — EXCLUSION
Who is blocked by language, disability, device access, cost, or procedure?
Material example: information is public but requires a device, language, motor action, visual capability, payment, or prior procedural knowledge not everyone has.
Failure test: use keyboard, small-screen, print/offline, language, cost, and alternate-channel checks with actual users where possible.
Does not prove: passing one accessibility standard guarantees universal usability.
THE RECEIPT
Six failures. Six chances to build before the emergency.
Outage receipt
What remained usable when the primary platform was unavailable?
Scarcity receipt
Which dependency disappeared and what honest fallback existed?
Error receipt
Which dependent claims were reviewed after a correction?
Capture receipt
Which challenge, repair, appeal, fork, or Exit path is actually usable?
Exclusion receipt
Who could not use the system and what alternative was built?
COMPETING INTERPRETATIONS
Keep the argument capable of surviving disagreement.
- Six categories can overlap: an outage may create scarcity, a captured platform can amplify exclusion, and founder absence can expose hidden vendor dependence.
- Some systems legitimately centralize authority or data for physical-hazard control, law, privacy, or operational coherence; the test asks whether those dependencies are understood, not whether centralization is automatically wrong.
- A failure test is a sample of system behavior, not proof of resilience under every future failure.
UNKNOWNS
Do not make certainty out of the missing piece.
- The Ministry has not empirically validated a weighting or score for the Six Fires and intentionally does not publish one.
- Some failure modes—financial insolvency, legal prohibition, physical disaster—may require additional tests outside this framework.
- The framework will need revision if repeated use reveals categories that are redundant, missing, or misleading.
SOURCE TRAIL
Follow the record.
- MFTAC-SRC-0056 NIST — Contingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1 (updated 11/11/2010)
- MFTAC-SRC-0057 Library of Congress — Use of Approved Inventory Systems / Storing Multiple Copies
- MFTAC-SRC-0055 ADA.gov — New Rule on Accessibility of State and Local Government Web Content and Mobile Apps
- MFTAC-SRC-0018 EU General Data Protection Regulation — Article 20
- MFTAC-SRC-0019 EU Data Act — Regulation (EU) 2023/2854
- MFTAC-SRC-0047 ICMJE — Corrections and Version Control
- MFTAC-SRC-0048 Crossref — Version control, corrections, and retractions
- MFTAC-SRC-0027 Nobel Prize — Economic Governance and the Commons
RELATED READING
CORRECTION RECEIPT
Source-status correction and editorial clarification are recorded under MFTAC-CORR-0020. The v20 wording treated the whole Rev. 1 publication as withdrawn; NIST’s records show the earlier 05/31/2010 record was withdrawn because the updated Final 11/11/2010 record superseded it. Through v27, the registered declaration said “LIGHT THE SAFE TEST.” v28 changes that phrase to “LIGHT THE FAILURE TEST” because the page tests named dependency failures rather than an undefined condition of safety. The source identity remains MFTAC-SRC-0056; claim classes, confidence, dependencies, and evidence weight are unchanged.
DO NOT ASK WHETHER THE SYSTEM LOOKS RESILIENT. LIGHT THE FAILURE TEST AND SEE WHAT STILL WORKS.