Docs

Approval workflow

Approval is the explicit decision between a validated repair proposal and anything leaving Seamward. Deterministic validation can establish that a candidate works on the evidence, but only an authorised reviewer can decide it should ship: that the fix addresses the real failure, the assumptions hold, and the destination is right.

What a reviewer checks

Members with the repairs:approve permission (owners and admins) review four things before deciding:

  1. The proposal addresses the observed failure. The operations map to the incident's findings, not to something adjacent.
  2. Every evidence reference and operation holds up. Each cited observation belongs to this incident; each operation stays within the bounded vocabulary.
  3. The replay result is clean. Mismatch paths and risk signals are absent, or understood and acceptable.
  4. The destination is understood. For a mapped repository, the review includes the real file, target branch, incident commit, and exact diff. Without source access, the proposal is explicitly presented as suggested remediation for manual implementation.

What a decision records

Approval and rejection are both explicit actions with persisted provenance: who decided, when, the reviewer's workspace role, and the rationale. Seamward captures the authenticated user's name and email when the decision is recorded. That immutable snapshot remains attached to the approval even if the account profile changes later. Seeded demonstration approvals are labelled as seeded demo evidence and never presented as a current user's decision.

Approval makes the validated artifact deliverable, and that is all it does; it does not apply, merge, or deploy anything. When source code is mapped, the approval record is bound to both the validated candidate and the exact source patch shown to the reviewer. Delivery refuses a patch with a different fingerprint.

Rejection keeps the incident open for further investigation, and the rejected proposal's record stays on the timeline: a rejected hypothesis is evidence too.

After approval

The Repair tab shows pull request delivery first when an exact repository patch is available, with manual issue delivery as the alternative. Both paths keep your engineering controls authoritative:

  • Standalone export: download the bundle (machine-readable manifest, readable report, TypeScript patch) and carry it into your repository yourself. No GitHub connection required.
  • GitHub delivery: create an evidence-linked issue, or a review branch and pull request, in the mapped repository. Choose Draft for further preparation or Open when the change is ready for repository review. Seamward never merges or deploys it; your CI, review, and release process take over from there.

Next steps