Attestation artifacts

A Claim Check run produces durable evidence, not just a verdict printed to your terminal and forgotten. Every check that ran is recorded as a content-addressed attestation on disk. Those are rolled up into one VSA (Verification Summary Attestation), the binding output. An optional trace sidecar carries additional detail for humans. Nothing here is sent anywhere by the tool; all of it stays on your machine, under .shipmoor/, until you choose to publish it.

Several producers, one shared surface

A run evaluates a change through several evidence producers at once, all pointed at the same change surface: the scan, review if you’re entitled to it, your build, your test suite, test integrity checks, artifact validation, every acceptance criterion that has a bound check, and, in full mode, the judge. They run concurrently, not one after another, so the total time a gate takes is set by the slowest single producer, not the sum of all of them.

Attestations on disk, content-addressed

Every producer’s outcome, each check result, each acceptance-item disposition, each judge sample, is written to disk as a content-addressed attestation under .shipmoor/attestations/. Content-addressed means an attestation’s own key is derived from a hash of what it contains: the same outcome always lands at the same address, and a changed outcome always lands at a new one. That’s what makes a verdict replayable after the fact. The evidence it was built from is sitting on disk, not just held in memory for the one process that computed it.

The VSA: the one binding output

Of everything a run writes, the VSA is the one binding artifact. It’s written to .shipmoor/claim-check.vsa.json by default, or to a path you choose with --vsa-out. It carries:

• the verdict (READY, READY WITH GAPS, BLOCKED, INCONCLUSIVE),
• the intent hash and the acceptance hash (the tamper seal on the frozen acceptance set),
• the policy version,
• per-item dispositions (one per acceptance criterion, with result and basis),
• judge results (for criteria the intent fidelity judge adjudicated).

The top-level verification_result field is the SLSA literal the verdict maps to. The VSA’s predicateType is https://slsa.dev/verification_summary/v1, the SLSA verification summary predicate, so it slots into an existing attestation ecosystem instead of inventing a new one.

{
  "predicateType": "https://slsa.dev/verification_summary/v1",
  "verification_result": "PASSED",
  "verdict": "READY WITH GAPS",
  "intent_hash": "sha256:...",
  "acceptance_hash": "sha256:...",
  "policy_version": 3,
  "per_item_dispositions": [
    { "ac": "order row persisted to orders", "result": "satisfied", "basis": "deterministic" },
    { "ac": "payment captured on checkout", "result": "satisfied", "basis": "deterministic" },
    { "ac": "refund function added", "result": "cannot_check", "basis": "no check yet" }
  ],
  "judge_results": []
}

A few things here are pinned on purpose. basis is either deterministic or byo_judge, never ambiguous, so a downstream consumer can filter out inferred evidence if it wants to. intent_hash and acceptance_hash are the tamper seal on the frozen acceptance set, checked again on every load.

The four verdicts and exit codes

The remaining exit codes are operational: 2 for a usage error, 3 for an engine crash. See Reading the verdict for exactly how these four are fused, and CLI reference for the full exit-code table.

The fix packet’s evidence, and the VSA’s dispositions

A run that isn’t fully READY also emits a fix packet (schema claim_check.fixes.v2) alongside the VSA. See Reading the verdict for the full walkthrough. The two artifacts describe the same evidence from different angles:

• The VSA’s per_item_dispositions is the durable, complete record: one entry per acceptance criterion, satisfied or not, with its basis.
• The fix packet’s fixes[].evidence is the actionable pointer into that same evidence: often the same attestation digest, file:line, or test id that backs a per_item_dispositions entry marked unsatisfied, surfaced as a to-do rather than a record.

Read the VSA to audit a run after the fact. Read the fix packet to act on it.

The trace sidecar (additive)

An optional trace sidecar carries per-criterion dispositions, masked judge traces, and the decomposed atomic check questions, for observability. Write it with --trace-out:

shipmoor claim-check . --vsa-out .shipmoor/claim-check.vsa.json \
  --trace-out .shipmoor/claim-check.trace.json

The sidecar is additive: it never changes the verdict, the VSA, or the exit code. You can publish it for debugging, or omit it, and the binding surface is identical either way. The VSA decides; the trace sidecar is for humans and audit.

The trace sidecar carries only masked signals and engine-built aggregate rationales, never raw source or raw per-sample model output. This is an invariant, not a best effort. See Privacy & telemetry.

Policy version

The policy_version field lets a downstream consumer detect that the floor’s policy shifted between two runs. When the policy changes, the version bumps, so a verdict produced under an old policy is distinguishable from one produced under a new one.

Tamper resistance and replay

The acceptance set is frozen at author time and hashed into the intent_hash and acceptance_hash carried in the VSA. A downstream consumer can compare those hashes against the acceptance set committed with the change and detect that intent was altered after the verdict was produced.

That, plus the attestations on disk, is what makes a Claim Check verdict reproducible rather than a one-time opinion: the same frozen acceptance set and the same fixed evidence set produce the same, byte-identical verdict, and you can replay it later, offline, from what’s stored in .shipmoor/, without re-running the whole check.

See also

• Reading the verdict: the four verdicts, the fix packet, and a worked example.
• Turning on the gate: when a BLOCKED or INCONCLUSIVE verdict should block a merge.
• BYO-Judge: the intent fidelity judge and the masked judge traces the sidecar carries.
• Privacy & telemetry: the masking boundary and what never leaves your machine.
• Test Evidence overview: the sibling producer whose signals compose into this same verdict.