What verdicts can Claim Check return?

Four lanes: READY, READY WITH GAPS, BLOCKED, and INCONCLUSIVE. READY means every required obligation was decided and satisfied on evidence. READY WITH GAPS adds disclosed, non-required vague obligations. BLOCKED means a witnessed deny exists: a failing bound check, a red build, a scan finding at the threshold, or a judge-confirmed divergence. INCONCLUSIVE means a required obligation is undecided, and the run lists the exact action that would decide it. Exit codes: 0 for the ready lanes, 1 for BLOCKED and INCONCLUSIVE, 2 for usage error, 3 for engine crash.

Do I have to write the acceptance set by hand?

No. The gate derives a reviewable draft from your frozen intent: atomic obligations, each with a statement and a verbatim source quote, honestly classed, including underspecified ones it refuses to pretend are checkable. Approving the contract is one commit: move the draft to .shipmoor/acceptance.yaml and push. The commit is the approval, reviewed with the code. Hand-authoring remains fully supported for teams that want to write the contract themselves.

What happens to an obligation nothing can check?

It 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, down to the set-scoped tag the authored check must carry. The next round binds that check by exact string join and the fail-at-base, pass-at-head transition decides it on the floor.

How does the judge decide to block?

Each residue obligation is decomposed into atomic check questions, sampled three times concurrently. A block requires at least two of three samples to agree AND the resolving pointer the judge cites to mechanically exist in the repo, so it cannot block on a hallucinated location. It can only BLOCK or ABSTAIN. It never passes a judgment obligation, so an inferred result can never be the basis for a READY.

My agent wrote the tests. Why should I trust them?

Because they are audited, not taken on faith. An authored check must fail at base and pass at head, so a check that was already green proves nothing. Deleted or gutted tests are caught by the test-integrity signals. And a sampled fidelity audit reads the check against its obligation and blocks, subtractively, when the check asserts something other than the obligation. The verdict then discloses the authored share: authored by agent, executed by your toolchain, decided by the floor.

Will Claim Check get in the way of shipping?

It produces a binding verdict, but whether that verdict blocks a merge is an opt-in CI policy. The CI gate runs floor-only against the committed contract: model-free, reproducible, binary, no secret. Locally, a run never leaves you stuck: a block carries its witnesses and an undecided obligation carries its action, so the next step is always on the screen.

Does my code get sent to a model or to Shipmoor?

No source is uploaded to Shipmoor, ever. Only masked signals leave the process to the agent: the obligation statement, a masked diff, and per file added symbols, never raw source beyond what the diff shows. The trace sidecar carries only masked signals and aggregate rationales, never raw per sample model output. This is an invariant, not a best effort.

A VSA is a Verification Summary Attestation. Claim Check writes one as JSON with the verdict, the intent hash, the acceptance hash, the policy version, per obligation dispositions, and judge results. The top level verification_result field is the SLSA literal the verdict maps to. Producer runs are wrapped as attestations inside in-toto envelopes keyed on the change digest, and the synthesizer rolls those up into the VSA, so the same round replays byte for byte.

Claim Check · the loop that proves done

Your agent says done. Evidence decides.

Coding agents ship plausible diffs that did not do what the task asked. Claim Check freezes what you asked for into atomic obligations, tells your agent exactly which check would prove each one, and verifies those checks on a model-free deterministic floor. A block always carries a witness. An undecided obligation arrives with its action, never a shrug. The judge audits what the floor cannot bind and only ever subtracts. Local, no source upload, no Shipmoor-hosted model.

Your agent finishes a task and writes a confident summary: “Added retry handling for failed Stripe payment webhooks.” The diff looks plausible. But did it bind a handler to the payment-failure event, or refactor something nearby and call it done? Claim Check answers that question with a binding verdict, and when it cannot answer yet, it tells your agent exactly what evidence would settle it.

The gate freezes your intent and derives a contract of atomic obligations you approve with one commit. A deterministic floor decides on evidence: checks bound to obligations that must fail at base and pass at head, your build, your tests, the scan, the review pass. An obligation nothing binds routes to a bring-your-own judge that samples three times, blocks only on two-of-three agreement with a pointer that resolves, and never passes anything. The fix packet hands your agent the checks to author, tagged per obligation; the next round binds them by exact join and the floor verifies them, with the authored share disclosed on the verdict. Four lanes (READY, READY WITH GAPS, BLOCKED, INCONCLUSIVE), one VSA attestation you can defend, and a repo that gets permanently easier to verify with every change.

Start a 30-day trial Start a 30-day trial Read the docs Read the docs

A block always carries a witness
The floor decides; the judge only subtracts
Authored by agent, executed by your toolchain, decided by the floor

frozen intent
derived contract
set-scoped check tags
fail at base, pass at head
VSA attestation
no source upload

$ shipmoor claim-check --intent-prompt "Add an IsPrivileged detector that inspects Containers, InitContainers and EphemeralContainers; make EnforcePrivilegedPolicy return an error instead of calling panic" --agent claude --diff main..HEAD . Claim Check  BLOCKED · coverage 100% · verified 0 · divergent 2 · judge-open 6  verification: build red · tests not checked · scan red  judge block AC-04 · ...detector runs, then it inspects all EphemeralContainers  → rules/check_privileged.go  judge block AC-06 · ...no panic statements are called instead of returning errors  → rules/check_privileged.go  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...    5 · 3/3 samples witnessed a divergence (≥2 agreement) → rules/check_privileged.go $ shipmoor claim-check --agent claude --diff main..HEAD .   # after the fix packet's tasks Claim Check  READY · coverage 100% · verified 8 · divergent 0 · gaps 0 · authored 6  verification: build green · scan green · 0 must-fix  floor pass  AC-04 · ...detector runs, then it inspects all EphemeralContainers  → sha256:8f1a1df7...  floor pass  AC-05 · ...EnforcePrivilegedPolicy is called, then it returns an error  → sha256:88b150ac...  judge ----  (no residue this run)Wrote attestation to .shipmoor/claim-check.vsa.json

A real run on a Kubernetes admission controller change: round one blocks a flawed diff with ten witnessed reasons; after the fix packet hands the agent its tasks, the terminal round verifies the corrected change on the floor, with the agent-authored checks disclosed.

Run it

Start from nothing but the prompt you gave your agent: the gate derives a reviewable contract and tells you what would decide each obligation. Commit the contract to approve it; run floor-only for a reproducible CI gate.

Gate a change against the prompt you gave your agent
shipmoor claim-check --intent-prompt "add retry to the webhook client" --agent claude --diff main..HEAD .
Run against the committed contract
shipmoor claim-check --agent claude .
Reproducible floor only, no model, no secret (the CI gate)
shipmoor claim-check --floor-only .
Author the contract by hand instead of deriving it
shipmoor claim-check --acceptance .shipmoor/acceptance.yaml .
Point the floor at your own toolchain
claim_check.runners.test: "pytest {ref}" # .shipmoor.yaml
Write the attestation to a path
shipmoor claim-check --vsa-out .shipmoor/claim-check.vsa.json .

Every run ends in one of four lanes: READY, READY WITH GAPS, BLOCKED with witnesses, or INCONCLUSIVE with the exact actions that would decide it. Exit codes stay binary for automation: the ready lanes exit 0, everything else does not.

Why you can trust the verdict

Every mechanism is built so a green light can only come from evidence, and every red one can defend itself.

Your model, your machine, your call

Claim Check runs locally. The deterministic floor never leaves your machine and never calls a model. Derivation and the judge run in your own agent under your own provider relationship. Shipmoor hosts no model and uploads no source. The result is a binding verdict and a VSA you can defend, not a vibe you have to trust.

How Claim Check works

The loop, not a single pass: freeze the intent, derive the contract, bind every obligation to a real check or route it honestly, run the evidence, and let the floor decide. The judge covers only the residue the floor cannot bind, and it can only block by citing a divergence or abstain. It never passes anything.

Freeze the intent and derive the contract
Bind each obligation to a check, or route it to the judge
Run the evidence: your build, your tests, scan, review
The floor decides; a block always carries a witness
The packet hands your agent the checks to author
Authored checks graduate obligations to the floor

Floor-only mode is what the CI gate runs against the committed contract: model-free, reproducible, binary, no secret. Full mode adds derivation, the judge, and the authoring loop. Approving the contract is one commit, reviewed with your code. You stay in control of what ships.

Check your next agent change against the claim

Install the CLI, sign in to Shipmoor IC, and run shipmoor claim-check on your next agent change with the prompt you gave it. Round one tells you the truth about what it can prove and hands your agent the tasks that would prove the rest. The terminal round is a verdict you can stake a merge on.

Get Shipmoor CLI

One installer. One shipmoor command. Free Community scans.

curl -fsSL https://dl.shipmoor.dev/install.sh | bash

Claim Check docs

Claim Check FAQ FAQ

The derived contract, the deterministic floor, the authoring loop, and the four-lane verdict vocabulary.

Your agent says done. Evidence decides.

Run it

Why you can trust the verdict

Shipmoor hosts no model

The judge only subtracts

Authored evidence is audited

No source upload

Your model, your machine, your call

How Claim Check works

Check your next agent change against the claim

Get Shipmoor CLI

Claim Check FAQ FAQ

Keep exploring

Your agent says done. Evidence decides.

Shipmoor hosts no model

The judge only subtracts

Authored evidence is audited

No source upload

Your model, your machine, your call

Check your next agent change against the claim

Get Shipmoor CLI

Claim Check FAQ FAQ

What verdicts can Claim Check return?

Do I have to write the acceptance set by hand?

What happens to an obligation nothing can check?

How does the judge decide to block?

My agent wrote the tests. Why should I trust them?

Will Claim Check get in the way of shipping?

Does my code get sent to a model or to Shipmoor?

What is a VSA?

Keep exploring