Claims

An agent that has already discovered something should not have to discover it again. If a previous run found that Ashgrove Freight's export limit is 100 records a page, that its fiscal year ends in June, that its billing contact changed last month, then the next run should start already knowing. Instead most agents re-fetch, re-ask, or re-guess, and the customer pays for the same lookup over and over.

Hyperstruck's learning shelf deliberately refuses to hold these. A learning has to generalize to be worth keeping, and a fact about one named company generalizes to nothing. So claims get their own shelf, with their own standards for trust, aging, and who is allowed to change them.

What a claim is

A claim is a single value, for a single property, of a single thing, and it never travels alone.

The last three columns are what separate a claim from a note in a database. They are what let the agent tell a claim somebody told it from one it inferred, tell a value from your own systems from a value that came off a web page an attacker could have written, and tell the world changed from we were wrong when a value moves.

The life of a claim

Nothing an agent encounters becomes usable knowledge just by being encountered.

Every candidate claim is scanned before it is stored, and the scan covers the exact text that gets saved, so a credential cannot reach the store through a value, a sentence, or a stray field. Claims drawn from a person's own data are marked private from the outset. Then one of three things happens.

Most claims go straight into use. They are ordinary observations from ordinary sources, and the agent can rely on them from the next run onward.

Some are held. A change to something consequential, arriving from a single source nobody has corroborated, waits. So does anything that came through a channel an attacker could have reached, such as a fetched web page or free text from an external system. A held claim is not merely unusable, it is invisible: it does not surface in recall and it cannot influence how the agent identifies anything. A poisoned value never even reaches the agent to be weighed.

A few are kept unfiled. Sometimes a claim is clearly real but Hyperstruck cannot tell which existing property it belongs to. Rather than guess and risk overwriting an unrelated claim, it stores the value as it stands and asks you. Guessing wrong here is destructive and hard to notice; declining to guess is merely untidy.

Your approval is evidence, not a verdict

The queue where a person releases a held claim is, structurally, the way into the agent's trusted knowledge. If a click simply cleared the flag, one distracted approval could launder attacker-authored text into something the agent treats as established. Review queues get rubber-stamped; any design that assumes otherwise is assuming away the actual risk.

So Hyperstruck treats your approval as evidence rather than as a verdict, and two things hold even if you approve everything in front of you.

A claim that arrived through a reachable channel stays marked that way permanently. It is not a flag curation can clear. It is derived from where the value came from, and nothing rewrites that.

Being readable is not the same as being able to give instructions. Your approval can raise a claim to something the agent may read, in a clearly fenced section of its context labeled as reference material. Nothing raises it to something that may steer: an approved-but-reachable claim is permanently refused from the places where a value would sit next to a tool's own instructions and get lifted straight into a call. That distinction is enforced in two different places, not one, precisely because a single control here would be a single point of failure.

And an approval is not permanent. A claim whose only support is a person's say-so has to earn independent corroboration or it quietly loses its release. The clock is not elapsed time. A claim about Ashgrove does not expire because nobody mentioned Ashgrove; it expires because the agent kept working with Ashgrove and nothing ever re-observed it. When it does lapse, nothing is enqueued and nobody is pinged; the agent simply stops relying on it. Re-asking a person to re-approve what they already approved is how review queues become noise.

Disagreement is held, not resolved

When two sources disagree, Hyperstruck does not pick a winner at write time. Both versions are kept, the disagreement is recorded, and a change of the binding value happens later, off to the side, and only when the newer value has genuinely out-earned the incumbent across independent sources. A single loud observation cannot flip a well-established claim.

Some properties are simply volatile. When a value keeps flip-flopping, that is usually a sign it is really two different properties wearing one name, so Hyperstruck proposes a split for you to confirm rather than continuing to overwrite.

Old claims are re-verified, not retracted

A claim nobody has contradicted but nobody has re-observed is not wrong, it is just old. Retracting it would bench a still-true claim and remove the very use that would have re-confirmed it. Instead it stays usable, is weighted down, and is marked verify before relying, so its next use becomes its re-verification. A successful use resets the clock.

What you operate

Three queues, each holding a decision only a person should make.

Alongside the queues you get a dossier per entity: every version of everything the agent knows about one thing, including the held and disputed versions the agent itself never sees. It answers what the agent knows about this customer, on whose word, and since when. It is also the surface a person exercises a data request against. Erasing an entity clears its claims, their history, and the standing those claims lent to your agent's learnings, in one operation. Be precise about the boundary, though: this is a claim-layer erasure, not a complete one, and the receipt it returns names what it did not reach. See Erase an entity.

Isolation

Claims are made of exactly the identifying material that learnings have scrubbed out, so they cannot be protected by removing content. They are protected by boundaries instead, enforced by the database rather than by application code.

An agent sees its own claims and nothing else. A person curating sees one organization's claims across its agents, and cannot name an agent they do not own. Security and data isolation sets out how those boundaries hold.

What claims are not

• Not a knowledge base you fill in. Claims are harvested from work the agent actually did. There is no authoring surface, because a claim with no source is exactly the thing this shelf exists to refuse.
• Not a cache. A cache returns what it stored. A claim carries who said it and how well corroborated it is, and can be held, disputed, or aged out on those grounds.
• Not overwritten in place. Every past value stays answerable.
• Not a learning. A claim can satisfy a learning's condition or contradict it, but it can never author one, and it can never override a safeguard.
• Not shareable, ever. A claim has no promotion path: there is no shared pool for claims and no way to mark one as shareable. Every claim starts private in the database itself, and the check that reads a stored privacy setting fails toward private if the value is missing or damaged. See Sharing and visibility.
• Not a place secrets live. Credentials are blocked before anything is stored or indexed, and high-sensitivity personal identifiers are dropped outright rather than redacted, because a claim cannot be generalized without destroying it.

What is on today

Related pages

• Memory for how claims sit alongside learnings and episodes
• Claims API for the curation endpoints
• Learning for the shelf that holds what to do rather than what is true
• Sharing and visibility for why claims never cross an agent boundary while learnings can
• Access control (FGA and RBAC) for the scopes that gate curation and erasure
• Security and data isolation for the wider isolation model