Grounded success
Why a Hyperstruck run will refuse to tell you it succeeded when it cannot show you what it observed.
In short
An agent that fails loudly costs you a retry. An agent that reports success it never achieved costs you the thing it was supposed to do, and you find out later. Hyperstruck refuses that second outcome: a run that cannot ground its answer in something it actually observed terminates honestly instead of claiming a win.
The expensive agent failure is not the one that crashes. It is the one that finishes, returns a confident paragraph, and is wrong. The certificate was never issued. The refund was never sent. The summary describes a report no tool ever returned. Nothing errored, nothing retried, and the run is filed as a success.
This gets worse with better reasoning, not better. A model that reasons harder is more able to construct a plausible account of work it did not do. So stronger reasoning has to come with an explicit refusal to stand behind claims it cannot support, or it just makes the failure more convincing.
Observation grounds action. Assertion never does.
Everything here follows from one distinction, and it is about where a statement came from, not where it sits in the prompt.
Evidence is what the run observed, meaning a tool actually read it, plus anything you explicitly supplied as a source of truth. Claims are everything the run generated, including the final answer.
A claim is checked against evidence. A claim is never checked against another claim.
That is why the input is typed rather than one blob of text. Your instructions and your reference material, the few-shot samples and the here is what good looks like blocks, are shown to the model but do not count as evidence. An answer supported only by an example you pasted into the goal is ungrounded. It gets dropped or demoted, never returned as though something confirmed it.
The two shapes of the failure
One defect shows up two ways, and the gate catches both.
| What it looks like | |
|---|---|
| An ungrounded claim | The answer asserts a fact that appears in no observation. The agent summarizes a report the tools never returned. |
| Self-contradicted success | The run's own output says a required part of the goal could not be done, and success is reported anyway. |
Two checks are enforced today, and a third is built but switched off. Does every claim in the answer trace back to something observed (faithfulness)? Does the run's own conclusion contradict its claim of having succeeded (contradiction)? A third check, for a requirement of the goal quietly dropped rather than attempted (completeness), is implemented but disabled in both tiers: on the calibration set its threshold could not be set without over-refusing honest work, so it stays off until a larger control set is available. Do not rely on it.
How strict the gate is depends on what the run can do
There are two tiers, and the difference is large. A run that only reads is checked for near-certain contradiction alone: faithfulness is dormant and the contradiction bar sits at 0.95, so a read-only run is refused only when it plainly contradicts itself. Full faithfulness checking applies to a run that can write, act destructively, or use an unannotated tool.
The practical consequence is worth stating plainly: an agent with no tools attached, which is what a quickstart agent looks like, sits in the read-only tier and has very little grounding applied. The guarantee on this page is strongest exactly where it matters most, on runs that can change something, and it is not a blanket promise about every run.
Some deliberate calibration sits behind those, because a gate that refuses honest work is worse than no gate:
- The first check is a ratio, not all-or-nothing. A mostly-grounded answer with one weak sentence is not thrown away.
- Contradiction is scored against the run's conclusion only, never its intermediate narration. A step that says now I will issue the refund is work in progress, and reading that as contradicting a completed run would refuse honest multi-step work constantly.
- A transient failure that a retry recovered is not held against an accurate success. A timed-out first attempt does not contradict order created and confirmed, provided the tool was safe to retry.
- A universal claim over a partial read is always refused. If the answer says all rows, every charge, or the entire ledger and the underlying read returned one page, the claim is refused regardless of what aggregate the answer quotes. A truncated read cannot substantiate a statement about the whole set.
What a refusal actually gives you
A refusal is not a crash and not an empty response.
The run terminates honestly and keeps the partial work, so everything genuinely completed is still there. The answer field is replaced with a fixed, value-safe sentence rather than the claim the engine just declined to stand behind, because that claim can echo real values from your data and surfacing it as the answer would defeat the point. The machine-readable reason still carries the specifics, so your own systems can see exactly what was refused and why.
The gate fails open, on purpose
If the verifier cannot run, the run completes as it otherwise would and emits a telemetry marker. This is deliberate. A verifier outage that mass-converted every success into a refusal would be a far worse failure than the one the gate exists to prevent. The guarantee is that Hyperstruck will not confidently lie to you; it is not a guarantee that the check ran on every single run regardless of infrastructure.
A consequential action cannot fire on something nobody read
The gate above governs what a run may claim. A second, tighter floor governs what it may do, and it runs before the act rather than after it.
Consequential actions carry checkable preconditions, and those preconditions are derived two ways. A model proposes them, which is useful but probabilistic: if it forgets one, an action fires unguarded. So a deterministic floor runs underneath and is merged beneath the model's work, reading only the plan's structure and your tools' declared return types. A floor condition can never be removed by the model omitting it.
The mechanism is entity grounding. An action targeting a structured identifier, an order, a matter, a loan, gets a precondition that the identifier must actually appear in something the run read. Present in a read is a match. Absent from every read while a sibling of the same type is present means the agent is about to act on the wrong record, and it is refused. Anything ambiguous abstains rather than guessing.
The floor also covers two cases worth naming:
- A write that depends on a read must not fire on an invented value. If a price write sources its number from a price read, and that read returned nothing, the write is blocked rather than proceeding on a plausible literal.
- A goal nothing can actually perform is refused before the irreversible part runs. If a goal says recalibrate the instrument and record the certificate, and your tools can record a certificate but nothing can recalibrate anything, Hyperstruck refuses the infeasible transformation rather than firing the attestation and reporting done.
What this is not
- Not a truth check. Hyperstruck verifies that a claim traces to something observed. It cannot tell you the tool told the truth. Garbage from a source you trusted is grounded garbage.
- Not an extra model grading the output. The checks are a purpose-built verifier and a deterministic floor, not a second model asked whether the first one did well. A judge that shares the generator's blind spots inherits them.
- Not optional for unfamiliar tools. This is the layer that makes an unproven tool safe to hand an agent, so it is exactly where it must not be switched off.
- Not a substitute for approval gates. Grounding decides whether a run may claim something. Human approval decides whether it may act at all. They answer different questions.
Related pages
- Reasoning for the run this sits inside
- Claims for how a remembered fact is held to a comparable standard
- Agents API for reading a refused run's reason