Hive Civilization
The Proof Layer for AIArchitecture
← all posts
Architecture · How it works

AFiR Runs Beside the Control Loop, Not Inside It

The most common pushback on a proof layer is a fair one: won't signing everything slow the system down? For robots, agents, and payment rails, speed isn't a nice-to-have. It's the whole point. AFiR answers that by how it's built. It watches from beside the workflow, never from inside the loop that has to stay fast.

If a receipt layer sits in the critical path, between a robot's perception and its actuators, between an agent's decision and its next tool call, between a payment's authorization and its settlement, then every receipt it writes adds delay the workflow has to pay for. That's the mistake AFiR is built to avoid.

The rule, laid out on the Machines page, is short: it rides next to the control loop, never inside it. The control loop keeps running at full speed. The receipt layer watches from the side.

What "sidecar" actually means here

A sidecar runs next to the thing it watches instead of sitting in line with it. AFiR-Stream lives beside the producer, whether that's an LLM emitter, a voice pipeline, an agent loop, or a robot rig, and it never blocks the producer. It anchors a session, and as the work moves forward, each meaningful stage sends off a receipt in the background while the control loop keeps running untouched. The subject keeps working. The witness records.

In practice, that means the receipt layer needs no changes to the control stack. The sidecar listens, anchors, and signs. The workflow never waits on the signature.

The design rule
AFiR-Stream anchors the session. Each stage emits receipts in the background while the control loop runs untouched at full speed. No changes to the control stack. The sidecar listens, anchors, and signs. It never touches the control loop.

Measure receipt latency separately

Because the two paths run separately, they should be measured separately. Receipt latency, meaning how long it takes the sidecar to queue, sign, and send, is a different number from control-loop latency or payment-rail latency. Mixing them up is how proof layers get unfairly blamed for slowness they didn't cause. AFiR keeps them apart on purpose. You measure receipt latency separately from control-loop or rail latency.

AFiR-Stream goes further and makes its own overhead something you can check instead of something you just have to take on faith. The sidecar measures its hot-path overhead per enqueue and puts those measurements right into the session receipt: max, p99, mean, the stated budget, whether it stayed within budget, and the sample count. The performance claim isn't marketing copy. It's a signed field you can read back. This post doesn't quote a specific latency number. The real numbers are whatever the sidecar records for your own workload.

What gets receipted: boundaries, not every byte

Running beside the loop only helps if the layer is also picky about what it signs. AFiR receipts event boundaries, the moments that actually carry meaning, not every telemetry packet. A session begins. A task gets accepted. A teleoperator takes control. A handoff or intervention happens. A task finishes. A cleanup or evaluation step locks in a result. Those are the points worth a signed record. The raw stream in between doesn't need to become a legal exhibit.

This is the same reasoning that lets a high-throughput robot data factory stay provable without throttling collection: receipt the boundaries that matter, and let the fast path stay fast.

The same shape across agents, machines, and payments

The sidecar pattern is not robot-specific. The receipt shape that anchors a humanoid's control loop is the same one that anchors an AI agent's action or a payment event:

  • Agents: the loop keeps deciding and calling tools. The sidecar records what the agent actually did without pausing it.
  • Machines and robots: telemetry and teleoperation stay real time. The witness signs the boundaries beside the rig.
  • Payments: settlement happens on its own rail. Receipt Relay signs the intent, evidence, and, when a tx hash is supplied, chain confirmation as a separate step in the background, so payment proof never holds up the transfer.

Every time, the receipts flow into the Hive Ledger, where they're searchable and anyone can check them offline. Again, this happens after the fact, off the hot path.

A proof layer that slows the system down gets turned off. AFiR is built to never earn that fate. It runs beside the loop, signs the boundaries in the background, and measures its own latency separately so the fast path stays fast.

This is the architectural partner to two other ideas: that receipts, not logs, are the real unit of proof, and that proof should be honest about its own limits. None of that matters much if capturing it slows the machine down. Running beside the control loop is how the proof layer stays honest and stays out of the way.

Witness without slowing the loop

See how AFiR-Stream sits beside your producer, signs event boundaries asynchronously, and records its own hot-path overhead in the session receipt.

AFiR sidecar Control loop receipts Receipt latency Asynchronous receipts Robotic telemetry Teleoperation receipts AI agent receipts Machine provenance
Private by design. Hive does not store your prompts. Every request is already receipted by a one-way SHA-256 fingerprint, not the words. Proof, not surveillance.