Providing intent

Claim Check checks a change against what it was asked to do, so it has to resolve what was asked from whatever you give it. This page covers where that intent can come from on the main gate, how precedence picks a winner when more than one source is present, how agreement across sources sets confidence, and what changes if you have an acceptance set that was committed before this model existed.

The three sources on the gate

shipmoor claim-check resolves intent from three places, in precedence order:

shipmoor claim-check . --intent-ticket ./tickets/PROJ-482.md
shipmoor claim-check . --intent-prompt "Add a Stripe webhook handler for failed payments (payment_intent.payment_failed)"
shipmoor claim-check .   # falls back to the acceptance file's own goal:, if you wrote one

A --intent-ticket freezes the intent from the ticket itself, rather than from the acceptance file’s goal. A --intent-prompt, a literal string or a path to a file holding one, outranks the acceptance file’s goal but is itself outranked by a ticket. The acceptance file’s goal: key sits underneath both, as the fallback that’s always there: if you hand-authored an acceptance set the way the quickstart walks through, you already wrote one, so a run with no --intent-ticket or --intent-prompt at all still has somewhere to resolve intent from.

--intent-ticket and --intent-prompt earn their keep in the cases where the acceptance file’s goal isn’t the best answer: a ticket is a more authoritative record than a hand-typed one-liner, and a prompt can capture exactly what the agent was told in a way a goal: written days earlier can’t.

Precedence decides the words; confidence measures the agreement

These are two different questions, and it’s worth keeping them apart.

Precedence decides whose text becomes the resolved intent: the words on the Intent: line, the words the probes and the judge actually work against. Only one source wins.

Confidence is a separate read on how much all the intent candidates you supplied, the winner and the also-rans alike, agree with each other. A --intent-ticket always wins the resolved text over a --intent-prompt sitting alongside it, but if the two disagree about what’s being built, that disagreement still drags confidence down, even though the ticket’s words are what actually gets used.

How agreement sets confidence

Confidence is low, medium, or high, and it’s reported on the Source: line of every run. Shipmoor compares every intent candidate that’s present, ticket, prompt, the acceptance file’s goal, for whether they roughly agree with each other in substance.

• One source present: confidence starts at the low end. A single --intent-prompt one-liner is a claim about the task, not something corroborated by anything else.
• Multiple sources present and consistent: confidence rises.
• Any pair that diverges enough: the whole resolution is flagged divergent, and confidence drops a step, even if some other candidate happens to agree with one side.

The rule is deliberately simple: if your ticket, your prompt, and your acceptance file’s own stated goal don’t roughly agree with each other, Shipmoor lowers its confidence rather than picking one of them arbitrarily and pretending the others didn’t exist.

For example, running:

shipmoor claim-check . --intent-prompt "Add a Stripe webhook handler for failed payments (payment_intent.payment_failed)"

against an acceptance file whose goal: reads "Add a Stripe webhook handler for failed payments" gives you two candidates that agree in substance:

Intent: Add a Stripe webhook handler for failed payments (payment_intent.payment_failed)
  Source: --intent-prompt, acceptance goal · agreement: consistent · confidence: medium

If that same acceptance file’s goal: instead read "Refactor the billing module's retry logic", a different task entirely, the two candidates diverge:

Intent: Add a Stripe webhook handler for failed payments (payment_intent.payment_failed)
  Source: --intent-prompt, acceptance goal · agreement: divergent · confidence: low

The --intent-prompt still wins precedence; it’s still the text on the Intent: line. But confidence reflects the fact that your own sources don’t agree on what this change is even for.

Why confidence matters

Confidence isn’t just a status readout. Two things key off it:

• The judge’s eagerness. The intent fidelity judge only adjudicates once the resolved intent clears a confidence floor. A low-confidence one-liner isn’t enough of a foundation for a model to adjudicate a divergence against.
• Gating. A low-confidence intent is a weak basis for a BLOCK. See Turning on the gate for how confidence factors into what’s allowed to fail a build.

Treat confidence as the honest answer to “how sure is Shipmoor about what this change was even trying to do,” a question that’s independent of whether the acceptance criteria happened to pass.

resolve: a wider preview

shipmoor claim-check resolve is a separate utility: no diff, no probes, no VSA, just the resolved intent.

shipmoor claim-check resolve --intent "…" --json     # -> goal_text, confidence, sources
shipmoor claim-check resolve --session run.jsonl

It draws on a wider set of sources than the main gate exposes directly, in its own precedence order:

The main gate command only takes --intent-ticket and --intent-prompt directly, plus the acceptance file’s goal: as a fallback; it has no --session flag. resolve is where you point Shipmoor at a richer source, an entire agent session transcript, and preview what intent it would resolve to before you commit to anything:

shipmoor claim-check resolve --session run.jsonl --json

This is a preview only. It tells you what the gate would see; it doesn’t run a single probe against your diff.

If you have an acceptance set from before this model

An acceptance file that carries a goal: but no --intent-ticket or --intent-prompt now freezes a different intent hash than it used to. If you have a committed .shipmoor/acceptance.json pin from before this changed, Shipmoor refuses it once with an acceptance-set tamper error instead of silently reinterpreting it under the new hash.

This isn’t a sign that anything was altered after the fact. It’s a one-time consequence of the intent hash’s own computation changing under you. Fix it the same way you approved it the first time: review .shipmoor/acceptance.yaml, then commit a fresh .shipmoor/acceptance.json. One fresh approval, and the pin holds again exactly as before.

Next

• Claim Check quickstart: writing and approving an acceptance set for the first time.
• Reading the verdict: the four verdicts, exit codes, and the VSA.
• Turning on the gate: how confidence factors into what’s allowed to block a build.
• BYO-Judge: the confidence floor the judge won’t adjudicate below.
• Privacy & telemetry: intent text is masked before anything else happens with it.