# Case Study Template — Founder-Mode Hardening Sprint > **This is a template.** It defines the structure for redacted incident > records drawn from the founder-mode hardening sprint. Each incident is a > placeholder to be filled with real, redacted bus data before publication. > No incident below contains actual operational data; the bracketed fields > mark where redacted content will be inserted. Real data lives in private > bus contents and must be redacted per the rules at the bottom of this > file before any public release. This template supports the manuscript's future empirical collection. The three placeholder incidents below cover the four candidate observations from the outline: 1. review debt needs first-class state, not scattered comments 2. a blocker should not count as productive last activity forever 3. local test claims should remain distinct from CI receipts 4. merge readiness needs evidence from checks, reviews, and scope boundaries Incident A covers observation 1. Incident B covers observation 2. Incident C covers observations 3 and 4 jointly. --- ## Incident Structure Each incident record uses the following fields: - **Incident ID** — anonymized identifier (e.g., `INC-A`). No real ticket refs. - **Date range** — month and year only, for privacy. No exact dates. - **Summary** — 1-2 sentences. No machine names, no file paths. - **Queue-control failure mode** — which of the 4 candidate observations this incident illustrates. - **Observed before-state** — source-linked state before the intervention, or explicitly unavailable. A retrospective guess is not an observation. - **Observed after-state** — source-linked state after the intervention, or explicitly unavailable. Put what the bus might have caught in a separate **counterfactual hypothesis**, never in the observed result. - **Bus messages involved** — redacted, type-only. One of: `STATUS`, `BLOCKED`, `DECISION`, `MILESTONE`. No message bodies. - **Metrics** — if available: review-lane latency, blocked-work recovery time, receipt completeness. Use ranges or rounded values, not raw timestamps. - **Lesson** — what this incident demonstrates about evidence/action separation. - **Selection and provenance** — selection rule, source snapshot/hash, inclusion/exclusion rationale, missing records, and whether the original evidence is publicly accessible or restricted. - **Measurement definition** — unit of analysis, denominator, time origin, cutoff, censoring, artifact revision, and exact calculation procedure. - **Alternative explanations** — workload, model, staffing, policy, or instrumentation changes that could explain an observed difference. --- ## Incident A — Review Debt as First-Class State - **Incident ID:** `INC-A` - **Date range:** `[month]/[year]` - **Summary:** [1-2 sentence redacted summary of a work item where review debt accumulated in scattered comments and chat, with no durable record.] - **Queue-control failure mode:** Observation 1 — review debt needs first-class state, not scattered comments. - **Before-state:** [Redacted. Describe how review requests lived only in transient channels, so pending reviews were invisible to anyone not reading those channels at that moment.] - **After-state:** [Redacted. Describe how a typed review receipt on the bus made the debt durable and queryable, if this was actually observed. Otherwise mark unavailable and state the hypothesized effect separately.] - **Bus messages involved:** `STATUS`, `DECISION` - **Metrics:** - Review-lane latency: `[range]` before / `[range]` after - Receipt completeness: `[%]` before / `[%]` after - **Lesson:** [Redacted. State the evidence/action separation point: posting a review need records evidence; it does not itself merge or approve anything.] --- ## Incident B — Blocker Staleness - **Incident ID:** `INC-B` - **Date range:** `[month]/[year]` - **Summary:** [1-2 sentence redacted summary of a work item that stayed "blocked" with no further activity, yet counted as productive last activity in the lane.] - **Queue-control failure mode:** Observation 2 — a blocker should not count as productive last activity forever. - **Before-state:** [Redacted. Describe how a stale blocker kept the lane appearing active, masking that no recovery action was underway.] - **After-state:** [Redacted. Describe how a typed `BLOCKED` with a re-evaluation signal, or a follow-up `STATUS`, exposed the stall and forced a decision to escalate, reassign, or close.] - **Bus messages involved:** `BLOCKED`, `STATUS`, `DECISION` - **Metrics:** - Blocked-work recovery time: `[range]` before / `[range]` after - **Lesson:** [Redacted. State the evidence/action separation point: a blocker is evidence of a stall, not authority to leave work parked indefinitely.] --- ## Incident C — Local Test Claims vs CI Receipts - **Incident ID:** `INC-C` - **Date range:** `[month]/[year]` - **Summary:** [1-2 sentence redacted summary of a work item where a local "tests pass" claim disagreed with the CI receipt, and merge readiness was asserted without source-linked evidence.] - **Queue-control failure mode:** Observations 3 and 4 — local test claims should remain distinct from CI receipts; merge readiness needs evidence from checks, reviews, and scope boundaries. - **Before-state:** [Redacted. Describe how a local status summary asserted merge readiness while the CI receipt had not completed or had failed, and no review or scope-boundary evidence was linked.] - **After-state:** [Redacted. Describe how a `MILESTONE` tied to a source-linked receipt separated the local claim from the CI result, and made the missing review/scope evidence visible before any merge.] - **Bus messages involved:** `STATUS`, `MILESTONE` - **Metrics:** - Disagreement between local summaries and CI state: `[count/rate]` before / `[count/rate]` after - Receipt completeness: `[%]` before / `[%]` after - **Lesson:** [Redacted. Distinguish a reported local observation from an independently checked, revision-bound result. A local claim can report an outcome, while a source-linked receipt can still be false, stale, or based on a different environment. State what was checked and by whom; neither form of evidence alone establishes authority to merge.] --- ## Redaction Rules Before publishing any incident filled from this template: - **No machine names.** Refer to hosts, runners, or environments by role only (e.g., "the CI runner"), never by hostname. - **No file paths.** Replace any path with a role label (e.g., "the config file under review"). - **No operator schedules.** No shift times, on-call rotations, or personal availability details. - **No live queue state.** No current lane contents, pending work counts, or real-time snapshots. Use only closed, historical ranges. - **No secrets.** No tokens, keys, internal URLs, or credentials. If a redacted field might leak one, leave it blank. The real incident data lives in private bus contents. Only fields that survive these rules may appear in the public case study. Do not populate an incident by combining separate events into an apparently observed narrative. Preserve a private mapping from redacted IDs to source records for authorized audit. Retain exact elapsed durations privately when permitted; if only rounded ranges can be released, identify the loss of precision and do not claim exact public reproducibility. If redaction removes the evidence needed to calculate an outcome, mark that outcome unavailable. The [synthetic replay fixture](replay_fixture.json) is a separate design example and must never be counted as a collected incident.