Docs

Incidents

An incident groups related findings for one integration and one failure kind into a single reviewable investigation. Instead of rebuilding a timeline from application logs, provider dashboards, and support tickets, the engineer opens one record whose every claim links to evidence.

The boundary

One incident covers related evidence from one integration and environment. A narrow boundary is what keeps the timeline reviewable: unrelated providers, environments, or failure windows get separate incidents even when one customer report surfaced them together. A missing-outcome incident, for example, is summarized as "3 ledger-entry outcomes missing after successful payment.settled events" and updates in place as the affected count changes.

The evidence timeline

An incident's timeline holds, in order:

  • The observations and structural findings that opened it.
  • Expected-outcome evaluations, with their correlation evidence.
  • Release context: which application version processed the failing traffic, first and latest occurrence.
  • Replay datasets and deterministic run results, once validation starts.
  • Repair proposal generation, validation checks, and the approval decision.
  • GitHub delivery records, when a repair leaves for review.

The timeline separates what was observed from what was inferred. Generated summaries and explanations are advisory; the linked evidence is the record.

Status semantics

  • Open means investigation is warranted. Incidents open automatically when findings group, within seconds to a minute of the triggering evidence.
  • Resolved records a reason, timestamp, and audit event. It does not delete evidence, and it does not claim a code change was deployed.
  • Missing-outcome incidents enter Verifying recovery when every affected source is satisfied again. The healthy state must hold for at least five minutes, or the rule's longer delay window. New missing evidence resets verification. A completed window auto-resolves with reason recovered without an authorised reviewer.
  • Workspace administrators and owners can record accepted-risk, false-positive, or superseded when recovery is not the reason. Manual resolution requires a meaningful note and stores an immutable snapshot of the signed-in reviewer's name, email, and role.

Boundaries

  • Every incident and linked record is workspace-scoped; foreign identifiers return not-found rather than confirming existence elsewhere.
  • Incident status never proves remediation; the evidence of recovery (the outcome appearing, the shape returning) does.
  • A merged pull request updates its GitHub delivery record, but it does not resolve the incident. Deployment and recovered traffic remain separate evidence.
  • For a pull-request repair, Seamward waits until an observation reports the merge commit as its deployed commitSha. That observation establishes the deployment boundary. Only correlated source and outcome observations received from that boundary onwards participate in repair recovery verification.
  • Verification starts only after at least one post-deployment source produces its expected correlated outcome. The incident keeps its historical failure count and evidence while showing the deployed commit, deployment observation time, healthy record count, and verification deadline.
  • Repair generation and delivery are separate, review-gated actions that happen from an incident, never because of one.

Next steps