What belongs in a SaSame incident report?
The report creates a factual operational record rather than a blame narrative.
- Collection
- evidence
- Updated
- 2026-07-29
- min read
- 2
- Version
- v1
An incident report records impact, detection, timeline, affected components, evidence, containment, recovery, verification and unresolved risk.
- Observed
- 2026-07-13 00:00 UTC
- Claim strength
- illustrative
- Dataset scope
- Zero incidents are logged in this register as of this page's last review. This page describes the intake fields a report would carry when one is logged — it is not itself a completed incident record.
- Methodology
- When triggered, a report binds the affected release/source SHA, the runtime observations that detected the issue, the containment or rollback action taken, and an external verification step confirming recovery — the same Evidence Record discipline used for routine compatibility checks, applied to an operational event instead.
- Limitations
- Because the register is currently empty, this page cannot yet demonstrate the format against a real incident. Treat it as a process description, not a track record — an empty register is evidence of "no incident logged," not evidence of "no incident occurred."
Illustrative — describes a method or schema, not a specific measured result
Purpose
The report creates a factual operational record rather than a blame narrative.
Method
Reports bind source and release SHAs, runtime observations, rollback actions and external verification.
A report is filed even when production traffic never moved — a failed candidate that was safely aborted before cutover is still a fact worth recording, not a non-event.
Boundary and limitations
A preliminary hypothesis remains labeled until evidence confirms or rejects it.
Examples
1- 01
Document a failed blue candidate and rollback receipt even when production traffic never moved.