No fix without sandbox proof

• claim · 01Shipped

  The repro must fail first

  A verification run writes a repro test, executes it against the unpatched code, and requires it to fail. Only then is the patch applied and the repro re-run. A test that passes before the fix proves nothing, so the pipeline treats it as a disqualification rather than a pass.
• claim · 02Shipped

  Tiers are audited, not asserted

  Tier A requires a full suite that passed. Tier B requires a non-empty suite that passed. Tier C must not have a passing suite. An independent audit function refuses to issue a certificate whose tier disagrees with its own evidence, and it checks that billability equals “tier is A or B” rather than trusting a flag.
• claim · 03Shipped

  The patch is real, and applied with zero fuzz

  Patches are authored by a model and applied by a parser that refuses to guess: if the file has moved under the diff, the applier reports a context mismatch and the author re-writes against the current bytes rather than fuzzy-matching its way into the wrong function.
• claim · 04Shipped

  A human merges. Structurally.

  Approval of a fix is denied to every non-human principal before any policy row is consulted; the scope that would grant it is filtered out of every agent token; and the approvals engine treats any action whose name ends in .merge as human-only so a future action fails closed. Underneath all three, the source-control client has no merge method at all.
• claim · 05Shipped

  The evidence is independently checkable

  The Proof Ledger bundle is signed Ed25519 over DSSE and published into an RFC 6962-style Merkle log with inclusion and consistency proofs. bucker-verify re-derives every claim in the document offline — it makes no network calls, and a test asserts that — and verifies the signature against a key you supply rather than the one shipped inside the file. The per-fix provenance certificate is signed with the same published key, so a stranger holding only the public half of it can check one; and the in-browser verifier does both jobs in your own tab, with no account, reporting authorship and self-consistency as two separate verdicts because a self-consistent forgery and a signed document are not the same thing.

  What is not true yet: We do not operate a public transparency log. Inclusion proofs check against checkpoints we sign ourselves, not against an independent witness, so the log is auditable but not yet monitorable by a third party watching for a split view.

The loop is documented rather than described — including the parts that are not built. See the remediation loop for verification tiers, provenance certificates and rejection memory, and Community Edition for exactly where the commercial line sits.