Hive Civilization
The Proof Layer for AIFoundations
← all posts
Foundations · Canonical

Logs Are Claims. Receipts Are Proof.

Every serious system writes logs. Logs are useful, and nothing here argues against them. But a log is a record a system keeps about itself — and when the stakes rise, a self-kept record is a claim, not proof. A receipt is the difference.

Logs run the operational world. They power dashboards, debugging, metrics, and incident review, and no team should stop keeping them. This post is not about replacing logs. It is about a narrower question that logs were never designed to answer: how does an outside party verify what happened without trusting the party that recorded it?

What a log actually is

A log is a statement a system makes about its own behavior, stored somewhere the same system controls. That is exactly what makes it useful for operations — it is cheap to write, easy to change, and fully under the operator's hand. Those same properties are what disqualify it as independent evidence. A log can be edited, backfilled, rotated, or lost. Even when it is perfectly honest, an outside reviewer has no way to distinguish an honest log from a convenient one. They are asked to take the operator's word for it.

That works right up until the moment it matters: an audit, a dispute, a regulator's question, an agent that did something no one intended, a customer asking why they should trust the data they bought. At that moment, "check our logs" is not an answer. It is a request for trust.

What a receipt is

A receipt is a signed, self-contained evidence object. It binds the facts that matter about an event — what happened, when, and under what conditions — and signs them so that anyone holding a public key can verify the record independently, offline, without the issuer's cooperation. A cryptographic receipt cannot be quietly edited after the fact without breaking its signature. It can be exported, forwarded, and checked by a third party who trusts none of the parties involved.

The shift is from "trust the story" to "verify the artifact." A receipt does not ask you to believe the operator. It hands you something you can check yourself.

The distinction that matters
A log is a claim a party keeps about itself. A receipt is proof a third party can verify without that party's cooperation. The value is not that receipts replace logs — it is that they survive scrutiny logs cannot.

Receipts are honest about their own boundary

A good receipt does not overclaim. It states plainly how an event was witnessed, so the reader knows exactly how much weight the proof carries. Was the event self-attested by another system and signed as described? Was it observed directly by the receipt layer? Was it confirmed against an independent source such as a public chain? Each of those is a different strength of evidence, and a receipt that hides the difference is worse than none.

That explicit edge — the point where proof stops and assertion begins — is what we call the proof boundary. Making it visible, rather than papering over it, is the entire point. We go deeper on this in Proof-State: The Missing Primitive for AI Systems.

Why this matters now

The gap between logs and receipts was tolerable when a human was always in the loop and volumes were low. AI changes both conditions at once.

  • AI agents make route decisions, call tools, and choose models faster than anyone reviews them. Agent receipts turn those actions into a verifiable chain instead of a reconstructed story.
  • Robots and machines generate enormous streams of telemetry and training data. Receipted robot data stays provable long after the rig moves on.
  • Stablecoin and agentic payments settle in seconds, but the context around them lives in the payer's logs. Payment receipts make intent, actor, and evidence independently checkable.
  • Regulated workflows in finance, healthcare, legal, and government increasingly require records an outside party can rely on. "The model did the right thing" is not a defense; a verifiable record is.

Where the receipts come from

Hive's receipt layer, AFiR, is designed to produce these records without becoming a bottleneck. It runs beside a workflow rather than inside it, signs the important event boundaries, and emits receipts asynchronously — the subject of AFiR Runs Beside the Control Loop, Not Inside It. Receipt Relay signs event and payment claims at explicit evidence tiers, and the Hive Ledger makes those receipts searchable and offline-verifiable.

Keep your logs. They are how you run the system. Issue receipts too — they are how you prove, to someone who trusts none of your systems, that it ran the way you say it did.

Logs answer "what did our system record?" Receipts answer "what can anyone verify?" As more decisions are made by machines and more value moves without a human watching, the second question is the one that will decide who is trusted.

Turn a claim into proof

See how Receipt Relay signs events into independently verifiable records — with honest evidence tiers and offline verification against a public key.

Logs vs receipts Cryptographic receipts AI audit trail Independent verification Agent provenance Machine receipts Proof boundary Hive AFiR