Docs

Repair proposals

A repair proposal is a bounded candidate fix for an incident, generated from its evidence. The division of authority is fixed: a model may propose and explain; deterministic validation decides whether the candidate holds; an authorised reviewer decides whether it may be delivered. Nothing in this pipeline is autonomous.

Advisory AI

Repair generation is enabled per deployment. When it is unavailable, every other part of the incident workflow (investigation, replay, manual repair, export) works unchanged.

What the model sees, and does not

Generation sends the provider a bounded package: the incident summary, its supported findings, and linked redacted evidence. It never includes provider credentials, raw traffic (none is stored), GitHub tokens, or unrelated workspace data. The returned candidate must parse against a strict proposal schema; free-form output is rejected before anything else happens.

The bounded operation vocabulary

Proposals are limited to deterministic transformations that replay can verify, currently:

  • Copy a value from one path to another (the field-rename repair: Copy $.candidate.email_address to $.candidate.email).
  • Coerce a path to a target primitive type (the type-change repair: Coerce $.candidate.salary to string).

Free-form code execution is outside the proposal contract. This is a deliberately small vocabulary: every operation in it can be validated against evidence, which is what makes the approval decision reviewable rather than a leap of faith.

The validation gate

A proposal reaches the approve button only after every check passes:

  1. The provider output parses against the proposal schema.
  2. Every evidence reference belongs to this incident; a candidate citing foreign evidence is rejected.
  3. The operation count and paths stay within safety policy.
  4. Replay produces the expected result on the incident's immutable dataset.
  5. When source code is mapped, Seamward locates the implementation at the incident commit, ports the bounded change to the current target branch, and records the exact file-level patch.

A failed or unsafe candidate stays unapprovable, permanently. Generate a new proposal only when the underlying evidence or provider output has changed; regenerating to "try again" against the same evidence produces the same verdict.

Reading a proposal like a reviewer

The incident's Repair tab presents the workflow in one place: failure reproduction, repair strategy, exact source patch when a repository is mapped, candidate replay result, engineer approval, and GitHub delivery. Seamward never presents a generated transformation as repository code. A source-backed proposal names the real file and shows its old and new line numbers before approval. Without a repository mapping, the result is labelled Suggested remediation and remains suitable for manual implementation only.

The explanation should refer only to evidence visible in the incident. Treat unsupported assumptions, references to operations outside the vocabulary, or claims about unrelated fields as grounds for rejection; the approval workflow is the checklist. When an exact source patch exists, approval records both the candidate fingerprint and the patch fingerprint. Delivery refuses a different patch.

Pending work limits

Only one active proposal is allowed per incident. A workspace can have ten proposals queued, generating or validating at once. Requests are also limited to five per user per workspace per minute and 20 across the workspace. Follow Retry-After when a request returns 429; a duplicate request returns the existing proposal identifier. See workload limits.

Next steps