Skip to main content

Incident Reconstruction

A system that looks fine now, a bundle of historical and operational artefacts, and a requirement to reason across time before touching anything.

Due: 30 April 2027 · Weight: 25%

Something broke. It may not look broken right now. Work out what happened, then fix it without breaking something else.

The system you receive does not obviously fail on inspection — it works, or appears to, under some conditions. Alongside it comes a bundle of commit history, configuration changes, incident tickets, and logs from around the time something went wrong. The reconstruction has to reason across that history, not just read the present-day code.

The eventual fix carries a real blast-radius concern, consistent with the intervention discipline built in Weeks 8–9. Substantial new functionality is not required.

What you submit

A reconstruction of what happened and why, each claim tied to a specific artefact; a diagnosis distinct from the surface symptom; a scoped intervention with at least one blast-radius check actually run; a verification argument tied to that diagnosis; and a statement of what remains uncertain.

How it’s marked

A correct patch that can’t be tied back to a reconstructed cause, or that verifies only that the original symptom vanished, does not receive full marks. A well-evidenced reconstruction with a properly scoped intervention can score highly even with one secondary factor left unresolved, provided that gap is stated rather than concealed.

The spec

The brief poses the problem and leaves room for a response. The spec is the fixed part: what a marker checks. Some lines can be checked mechanically; the rest call for judgement.

How it is marked

CriterionWeight
Historical evidence interpretation and reconstruction20%
Handling of conflicting or ambiguous evidence15%
Diagnosis quality and justification15%
Intervention justification and scoping20%
Verification quality20%
Investigation record / communication10%