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 objection to a proof layer is a fair one: won't signing everything slow the system down? For robots, agents, and payment rails, latency is not a nicety — it is the product. AFiR answers the objection by design. It witnesses from beside the workflow, never from inside the loop that has to be 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 is latency the workflow has to pay for. That is the design mistake AFiR is built to avoid.

The principle, stated on the Machines page, is short: sidecar to the control loop, never inside it. The control loop keeps running at full rate. The receipt layer watches from the side.

What "sidecar" actually means here

A sidecar runs next to the thing it observes rather than in series with it. AFiR-Stream lives beside the producer — an LLM emitter, a voice pipeline, an agentic loop, a robot rig — and the sidecar never blocks the producer. It anchors a session, and as the work proceeds, each meaningful stage emits a receipt asynchronously while the control loop runs untouched. The subject keeps working; the witness records.

Concretely, that means the receipt layer requires no changes to the control stack. The sidecar listens, anchors, and signs. The workflow does not wait on the signature.

The design rule
AFiR-Stream anchors the session; each stage emits receipts asynchronously while the control loop runs untouched at full rate. Zero 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 are decoupled, they should be measured separately. Receipt latency — how long it takes the sidecar to enqueue, sign, and emit — is a different number from control-loop latency or payment-rail latency, and conflating them is how proof layers get unfairly blamed for slowness they do not cause. AFiR keeps them distinct on purpose: measure receipt latency separately from control-loop or rail latency.

AFiR-Stream goes a step further and makes its own overhead auditable rather than asserted. The sidecar measures its hot-path overhead per enqueue and embeds those measurements — max, p99, mean, the declared budget, whether it stayed within budget, and the sample count — into the session receipt itself. The performance claim is not marketing copy; it is a signed field you can read back. (This post does not quote a specific latency figure; the live numbers are the ones 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 selective about what it signs. AFiR receipts event boundaries — the moments that carry meaning — not every telemetry packet. A session begins. A task is accepted. A teleoperator takes control. A handoff or intervention occurs. A task completes. A cleanup or evaluation step binds a result. Those are the points worth a signed record; the raw stream in between does not 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, asynchronous step, so payment proof never gates the transfer.

In every case the receipts flow into the Hive Ledger, where they are searchable and offline-verifiable — again, after the fact, off the hot path.

A proof layer that slows the system down will be turned off. AFiR is built to never earn that fate: it runs beside the loop, signs the boundaries asynchronously, and measures its own latency separately so the fast path stays fast.

This is the architectural companion to two ideas: that receipts, not logs, are the unit of proof, and that proof should be honest about its own boundary. None of that is worth much if capturing it slows the machine. 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