Proof-State: The Missing Primitive for AI Systems

A system that acts on information should know how much that information can be trusted. Today most systems collapse that question into a single bit: the data is either present or absent. But "present" hides a spectrum. Some facts were independently verified. Some were observed first-hand. Some were merely asserted by another party and passed along. Treating all three as equally true is how bad inputs quietly become confident outputs.

Proof-state is the primitive that keeps that distinction machine-readable — so that a system, an auditor, or another agent can ask not just "what happened?" but "how well is that established, and what am I allowed to do about it?"

Evidence tiers: how a fact was witnessed

Proof-state starts with an honest label on every receipt describing how the event was witnessed. In Hive's Receipt Relay, those tiers are explicit:

• Self-attested — another system described the event, and Hive signed that description as stated. The signature proves the claim was made and has not been altered; it does not independently confirm the claim is true.
• Relay-observed — Hive itself made the call and signed hashes of the request and response, so the receipt reflects what Hive directly saw, not only what it was told.
• Chain-verified — the event was confirmed against an independent source, such as reading a transaction back from a public chain when a transaction hash is supplied.

These are ordered by strength, and the point is not to make everything chain-verified. Most events legitimately live at the self-attested or relay-observed tier. The point is that the receipt says which tier it earned, and never dresses a weaker one up as a stronger one.

The weakest proof boundary sets the ceiling

Real workflows are chains of events, and a chain is only as strong as its weakest link. If nine steps are relay-observed and one is self-attested, the honest summary of the whole is "contains a self-attested step." Proof-state carries that forward as the weakest proof boundary — a single, conservative read of how far the group can be trusted. This is what stops a long, mostly-solid record from being marketed as fully verified because most of it was.

Permitted next actions

Proof-state is not only backward-looking. Because it encodes how well something is established, it can gate what happens next. A high-value action might require a relay-observed or chain-verified boundary before it proceeds; a self-attested boundary might be allowed only to hold, review, or route for a stronger check. That turns proof from a passive audit artifact into an input a system can act on in real time — and it keeps the decision honest, because the gate reads the same conservative boundary everyone else can verify.

R3Pv: where receipts become grouped proof-state

Individual receipts describe single events. Most questions are about a set of them — a session, a task, a dataset slice, a payment flow. R3Pv is the layer that groups receipts into a signed proof vector: one object that reports the group's verification depth, its weakest proof boundary, a healing state, and a routing recommendation. It is how proof-state scales from one event to a whole workflow without asking a reviewer to replay every underlying receipt by hand.

To be precise about scope: R3Pv reports and groups proof-state honestly; it does not manufacture verification that the underlying receipts do not carry, and it does not reverse events that already happened. Its value is an accurate, signed summary — not a stronger claim than the evidence supports.

Why AI needs this specifically

Human-paced systems could resolve proof questions after the fact, one incident at a time. AI agents, robots, and payment rails act continuously and at volume, so the "how well is this established?" question has to be answered inline and in a form other systems can read.

• Agent receipts gain a proof-state so a downstream agent knows whether an upstream decision was observed or merely claimed.
• Machine and robot data carries a proof-state that survives long after collection, so buyers can separate high-trust trajectories from lower-trust ones.
• Payment receipts use tiers directly: a self-attested intent is not the same as a chain-verified settlement, and proof-state keeps them distinct.

Systems already track what is true and what is pending. Proof-state adds the state they have been missing: what is proven, how well, and what that permits next.

Proof is not a single bit. Proof-state is the primitive that treats it as what it actually is — a spectrum, labeled honestly, that a machine can reason about. This builds directly on why receipts, not logs, are the unit of proof, and it depends on a receipt layer that can witness events without slowing them down.