{
  "slug": "fault-model",
  "term": "Fault model",
  "aliases": [
    "crash fault model"
  ],
  "definition": "A fault model specifies the failures a test or analysis admits, their scope and timing, and which system state and components remain available afterward.",
  "note": "For storage recovery, name the failed component, volatile state that is lost or preserved, permitted write reordering or tearing, and whether faults may occur again during recovery. SQLite's crash harness models unsynchronized-write effects rather than treating process termination alone as a device-power-loss test. Keep the fault model separate from the workload, the recovery correctness oracle and the real-world frequency of failures.",
  "status": "research",
  "advantages": [],
  "limitations": [
    {
      "text": "A passing test establishes only the explored cases under its stated assumptions; it is not evidence of resilience to excluded faults.",
      "citationIds": [
        "sqlite-tests"
      ]
    }
  ],
  "related": [
    "fault-injection",
    "bounded-crash-testing",
    "crash-test-oracle",
    "crash-consistency",
    "persistence-ordering"
  ],
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "citations": [
    {
      "id": "sqlite-tests",
      "title": "SQLite project. How SQLite Is Tested, sections 3.3-3.4: crash and compound-failure tests.",
      "url": "https://sqlite.org/testing.html",
      "accessed": "2026-10-16"
    },
    {
      "id": "hesela",
      "title": "Hesela. Crash-consistency tests: the oracle is part of the result.",
      "url": "https://hesela.com/analyses/crash-testing-oracles-and-bounds/",
      "accessed": "2026-10-16"
    }
  ],
  "updated": "2026-10-16"
}