How Shipmoor Claim Check works

This is the claim layer. Where the deterministic scan answers structural questions with the same finding ids every time, Claim Check answers the question no linter can: did this change do what its author claimed it would do? Coding agents make that question urgent, because they ship plausible diffs that did not do what the task asked, and they say “done” either way.

The answer is a loop, not a single pass. Every run tells the truth about what it could decide, who decided it, and exactly what evidence would decide the rest. Every quoted terminal line below comes from a real run on a Kubernetes admission controller change.

---

1. What a run produces

One command on a repo, one binding verdict, one replayable attestation:

shipmoor claim-check --agent claude --diff main..HEAD .

The verdict is one of four lanes, and the lanes mean exactly what they say:

• READY: every required obligation was decided and satisfied, on evidence.
• READY WITH GAPS: satisfied, with vague non-required obligations disclosed.
• BLOCKED: a witnessed deny exists, a failing bound check, a red build, a scan finding at the threshold, or a judge-confirmed divergence. A block always carries its witness; ignorance never renders as refutation.
• INCONCLUSIVE: a required obligation is undecided. The run tells you the exact action that would decide it. This lane exists so the gate never has to choose between crying wolf and rubber-stamping.

The attestation (.shipmoor/claim-check.vsa.json) records the frozen inputs, the evidence digests, and the verdict, so the same round replays byte for byte.

---

2. Freeze: the intent becomes immutable

The intent comes from ranked sources: a ticket, the first user turn, or the prompt you gave your agent. It is snapshotted verbatim and hashed. Everything downstream measures fidelity against this frozen artifact, and re-running the gate never silently re-derives it mid-loop.

---

3. Compile: the contract derives itself

You do not hand-write process artifacts to start. The gate decomposes the frozen intent into atomic, binary obligations, each with a statement and a verbatim source quote, honestly classed. On a real prompt about comped admin access, one derived obligation was too vague to check, and the gate said so instead of pretending:

AC-04 · underspecified · required  A comped admin displaying lifetime access
  should be granted continued access to all features and services

The derived set is a reviewable draft. Approving it is one commit: move it to .shipmoor/acceptance.yaml and push. The commit is the approval, reviewed with the code in your normal PR flow. No ceremony, no separate confirm step, and the committed contract is hashed so the denominator can never be quietly shrunk.

---

4. Bind: every obligation gets a real check, or an honest route

Each obligation binds to a concrete check through a finite set of mechanisms: a test that must fail at base and pass at head, a presence check, a command exit, a structured tool field, or an artifact validator. The stack knowledge lives in your own commands (claim_check.runners.test: "pytest {ref}"), never in the engine.

Binding is layered: your explicit hint wins, then an exact tag join for checks authored to claim an obligation, then a conservative inventory match over the test files your change already carries, then a bind-time agent proposal that is pinned and hashed. An obligation nothing binds is never parked as unknowable and never denied for being unknown. It routes to the judge as residue, and the run hands you the authoring action that would graduate it:

needs evidence — each undecided obligation with its action:
  ~ AC-04 · ...inspects all EphemeralContainers — no check bound — author a
    covering check carrying the tag 'ac_04_0f38996e'; it must fail at base
    and pass at head

That tag is set-scoped and derived, so two tasks never collide, and the next round binds the authored check by exact string join. No fuzzy matching between obligations and evidence, ever.

---

5. Run: the evidence fabric

Producers run concurrently over the committed change: your build command, your test runner, the deterministic scan, the review pass, test evidence harvested from runs your pipeline already made, and the bound checks in an ephemeral sandboxed worktree. A test bound to an obligation must fail at base and pass at head; a check that was already green proves nothing. A producer that cannot run says so and is disclosed, never counted green.

---

6. Decide: the floor carries the verdict

The floor is a typed deny set evaluated by a native, hermetic, model-free engine: allow if and only if nothing denies. On the flawed detector change, it read like this:

Claim Check  BLOCKED · coverage 100% · verified 0 · divergent 2 · judge-open 6
  floor FAIL  AC-07 · ...all referenced identifiers have their packages imported  → sha256:3cb521a0...
  why blocked — 10 actionable, each with resolving evidence:
    1 · the configured build did not exit green → sha256:fcbf486e...

Coverage is the credibility meter and it is never faked: it reads decided over total for the obligations the floor actually weighed, and a round with nothing bound says “no checks bound this round” in words, never a bare zero that looks like a measurement.

---

7. Audit: the judge only ever subtracts

The bring-your-own judge covers the residue the floor cannot bind. It decomposes each obligation into atomic yes or no checks, samples each three times, and confirms a block only when at least two of three samples agree AND the cited evidence pointer resolves. It can block or abstain. It cannot pass, by type. On the flawed change it witnessed six divergences; on the corrected change it had nothing left to say:

judge ----  (no residue this run)

The judge also audits the evidence itself. When your agent authors a check, a sampled fidelity audit asks one grounded question: does this check assert this obligation, or something else? In real use it refused three successively thin versions of an authored check before accepting the faithful one. A check that merely transitions does not survive; it has to encode the obligation.

---

8. The loop closes

Round one on the flawed change: BLOCKED with ten witnessed reasons. The fix packet, the same content as the human render but machine-readable, handed the agent its next task per obligation. The code was corrected against the contract, the tagged checks were authored, and the terminal round read:

Claim Check  READY · coverage 100% · verified 8 · divergent 0 · gaps 0 · authored 6
  verification: build green · scan green · 0 must-fix
  judge ----  (no residue this run)
Wrote attestation to .shipmoor/claim-check.vsa.json

The authored 6 crumb is provenance, disclosed on every verdict: authored by agent, executed by your toolchain, decided by the floor. And the contract plus its tagged checks stay in the repo, so the next change to this area starts with obligations that already have oracles. Verifiability compounds.

---

9. In CI

The CI gate runs floor-only against the committed contract: binary READY or BLOCKED, fully reproducible, no model, no secret. The judge belongs to the local loop where your agent lives; at CI its recorded signal is advisory. An undecided required obligation fails closed at the gate until it graduates or you demote it at commit time.

---

10. What Claim Check never does

It never passes on a model’s opinion; a green light rides only deterministic evidence. It never fabricates a check, a count, or a green cell; absence is disclosed. It never learns your language; stack knowledge stays in your commands and path patterns. It never uploads source or calls a Shipmoor-hosted model; the judge is the agent you already run. And it never buries the one thing you need at the end of a run: what to do next.

Claim Check is an IC feature on the claim_check entitlement, paid in whole. Start on the Claim Check page, or read the pricing for the tier line.