Verdicts require
Epistemics

{
  "incident": "042",
  "revision": 1,
  "recorded_at": "10:00",
  "supersedes": null,
  "verdict": "degraded",
  "scope": "Gateway symptoms; root cause unverified",
  "observations": [
    {
      "id": "obs-1",
      "statement": "Gateway 5XX is 12% and p95 is three seconds. Checkout was deployed two minutes earlier.",
      "evidence_refs": [
        "gateway metrics",
        "deployment history"
      ]
    }
  ],
  "inferences": [
    {
      "statement": "The deployment may be involved. There is no causal evidence yet.",
      "supported_by": [
        "obs-1"
      ],
      "alternatives": [
        "A shared dependency is slow",
        "The deployment changed request behavior"
      ]
    }
  ],
  "confidence": {
    "level": "low",
    "basis": "Low confidence · timing alone"
  },
  "unknowns": [
    "Which routes fail; the cause of the timeouts"
  ],
  "discriminating_checks": [
    "A shared dependency could explain failures beyond Checkout."
  ],
  "next_action": "Compare failing routes and trace their dependencies.",
  "valid_through": "10:03",
  "reassess_if": "New evidence contradicts the explanation, or traffic or configuration changes"
}

{
  "incident": "042",
  "revision": 2,
  "recorded_at": "10:03",
  "supersedes": 1,
  "verdict": "degraded",
  "scope": "Both API routes; sampled request traces",
  "observations": [
    {
      "id": "obs-2",
      "statement": "Checkout and Catalog both spend most of their request time waiting on Inventory. Payments stays fast.",
      "evidence_refs": [
        "Checkout traces",
        "Catalog traces",
        "Payments latency"
      ]
    }
  ],
  "inferences": [
    {
      "statement": "Inventory is the shared slow dependency. The trigger is still unknown: Checkout could also be overloading it.",
      "supported_by": [
        "obs-2"
      ],
      "alternatives": [
        "Checkout is overloading Inventory",
        "Inventory changed independently"
      ]
    }
  ],
  "confidence": {
    "level": "medium",
    "basis": "Moderate confidence · traces converge"
  },
  "unknowns": [
    "What triggered the shared slowdown"
  ],
  "discriminating_checks": [
    "Trace more requests; a shared delay does not identify what started it."
  ],
  "next_action": "Separate Inventory’s queueing time from database execution time.",
  "valid_through": "10:06",
  "reassess_if": "New evidence contradicts the explanation, or traffic or configuration changes"
}

{
  "incident": "042",
  "revision": 3,
  "recorded_at": "10:06",
  "supersedes": 2,
  "verdict": "degraded",
  "scope": "Inventory pool; database capacity must be checked",
  "observations": [
    {
      "id": "obs-3",
      "statement": "Inventory waits 2.4 s for a database connection; queries take about 20 ms. At 09:56, its pool limit changed from 40 connections to 4 per replica.",
      "evidence_refs": [
        "pool wait histogram",
        "database spans",
        "09:56 configuration diff"
      ]
    }
  ],
  "inferences": [
    {
      "statement": "The smaller connection pool is the leading explanation. Requests can queue before reaching an otherwise fast database.",
      "supported_by": [
        "obs-3"
      ],
      "alternatives": [
        "Another bottleneck coexists with pool starvation"
      ]
    }
  ],
  "confidence": {
    "level": "medium",
    "basis": "Leading hypothesis · mechanism and timing fit"
  },
  "unknowns": [
    "Whether restoring the pool will relieve the bottleneck; database headroom"
  ],
  "discriminating_checks": [
    "If restoring the pool does not reduce waiting, reconsider the diagnosis."
  ],
  "next_action": "Verify database headroom and restore the previous pool setting on one replica.",
  "valid_through": "10:10",
  "reassess_if": "New evidence contradicts the explanation, or traffic or configuration changes"
}

{
  "incident": "042",
  "revision": 4,
  "recorded_at": "10:10",
  "supersedes": 3,
  "verdict": "degraded",
  "scope": "Requests routed through the canary; other replicas still affected",
  "observations": [
    {
      "id": "obs-4",
      "statement": "With database capacity checked, one replica gets its previous setting back. At comparable load, pool wait falls to 30 ms; unchanged replicas still queue.",
      "evidence_refs": [
        "canary pool metrics",
        "matched request traces",
        "unchanged replicas"
      ]
    }
  ],
  "inferences": [
    {
      "statement": "Strong evidence that the pool change caused the bottleneck. This canary—a trial on one replica—does not establish overall recovery.",
      "supported_by": [
        "obs-4"
      ],
      "alternatives": [
        "Differences in workload may explain part of the canary improvement"
      ]
    }
  ],
  "confidence": {
    "level": "high",
    "basis": "Strong support · one replica, comparable load"
  },
  "unknowns": [
    "Whether other replicas and request types will improve"
  ],
  "discriminating_checks": [
    "Check whether the improvement holds across replicas and request types."
  ],
  "next_action": "Restore the setting across replicas and check end-to-end recovery.",
  "valid_through": "10:14",
  "reassess_if": "New evidence contradicts the explanation, or traffic or configuration changes"
}

{
  "incident": "042",
  "revision": 5,
  "recorded_at": "10:14",
  "supersedes": 4,
  "verdict": "degraded",
  "scope": "All replicas restored; upstream retries remain",
  "observations": [
    {
      "id": "obs-5",
      "statement": "After rollout, gateway p95 is 900 ms and 5XX is 2.8%. User traffic is unchanged, but traces show three Inventory attempts per original call on average.",
      "evidence_refs": [
        "gateway latency",
        "attempts per request",
        "Inventory queue depth"
      ]
    }
  ],
  "inferences": [
    {
      "statement": "The pool change was a trigger. Upstream retries appear to be sustaining excess load after that trigger is removed.",
      "supported_by": [
        "obs-5"
      ],
      "alternatives": [
        "Another source of load may be keeping queues busy"
      ]
    }
  ],
  "confidence": {
    "level": "medium",
    "basis": "Retry amplification likely · extra attempts measured"
  },
  "unknowns": [
    "Whether reducing retries will drain the remaining queues"
  ],
  "discriminating_checks": [
    "If queues persist after retries fall, investigate another source of load."
  ],
  "next_action": "Apply the approved retry budget, which caps extra attempts; watch queues and successful requests.",
  "valid_through": "10:30",
  "reassess_if": "New evidence contradicts the explanation, or traffic or configuration changes"
}

{
  "incident": "042",
  "revision": 6,
  "recorded_at": "10:30",
  "supersedes": 5,
  "verdict": "recovered-under-observed-load",
  "scope": "Observed load and time window; not a universal guarantee",
  "observations": [
    {
      "id": "obs-6",
      "statement": "For ten minutes at comparable incoming load, queues stay drained, p95 is 270 ms, and 5XX is 0.3%.",
      "evidence_refs": [
        "10-minute gateway window",
        "queue depth",
        "incoming traffic"
      ]
    }
  ],
  "inferences": [
    {
      "statement": "Recovery is supported for this traffic level. Peak-load behavior and the reason the configuration changed remain unverified.",
      "supported_by": [
        "obs-6"
      ],
      "alternatives": [
        "Recovery may not hold at higher load"
      ]
    }
  ],
  "confidence": {
    "level": "high",
    "basis": "Recovery observed · current traffic level"
  },
  "unknowns": [
    "Peak-load behavior; why the configuration changed"
  ],
  "discriminating_checks": [
    "Reopen the incident if errors or queueing return, especially at higher load."
  ],
  "next_action": "Continue monitoring and investigate how the pool configuration changed.",
  "valid_through": "10:40",
  "reassess_if": "Errors, queueing, traffic, topology, or configuration materially change"
}