Hive-operated receipt infrastructure
Hive may sign or countersign a supported receipt. A second Hive-operated key is not an organizationally independent witness. Check the actual signature, trusted issuer configuration and captured scope; the illustration below is not a signed artifact or a neutral-party certification.
AFiR creates signed records for captured inference steps. Sign-before-action and complete capture require integration tests, including bypass paths. Historical reference figures: signed model first token median 112ms (p90 145ms), perceived first byte median 59ms. These figures were not remeasured in this review. Your latency depends on your models, hardware, and routing. Patent pending.
Same cryptographic receipt either way: ML-DSA-65 (NIST FIPS 204) + Ed25519, checkable offline or by URL. The only question is whether AFiR runs the inference, or simply attests inference you ran yourself.
Send a prompt to /v1/afir/run. AFiR fragments, routes, and signs every sub-step before the output moves. Fastest path to faster, cheaper, signed inference.
Already running your own model on your own stack? Hand us {input, output} at /v1/afir/sign. There's zero routing and zero model change. The output just becomes signed inference.
The DAG and standard-inference column are modeled illustrations, not a paired benchmark. Running the demo requests an AFiR response; only supported returned fields are displayed as service-reported. This page does not execute signature verification. The modeled $0.0728 and 18.4s baseline excludes unmeasured retries, selection overhead and full compute costs.
Illustrative receipt structure, not a signed artifact. Actual coverage, signature algorithm and root inclusion must be checked for the returned endpoint-specific receipt.
An integration can capture retrieved context, tool calls, cross-agent handoffs, model identity and cache references as signed statements. Sign-before-action and complete capture require tests of the specific integration and its bypass paths. An individual receipt does not establish that every pipeline action was observed or signed.
Every primitive above can be reached three ways. Pick the one that fits how you run inference. All three sign with the same real ML-DSA-65 key and verify against the same public key.
POST your fragments to any signer.thehiveryiq.com/sigr/… endpoint and get a signed receipt back. Every endpoint has a free /verify counterpart. No account, no key, no card. This is the fastest way to prove a single receipt.
Best for: trying a primitive, verifying someone else's receipt, low-volume signing.
Get a key in minutes at onboard, then POST to /v1/afir/run. AFiR fragments, routes across models, and signs every sub-step before the answer moves. It's metered and uncapped, so you pay for exactly what you sign.
Best for: production agents that want faster, cheaper, fully-signed inference end to end.
Already running your own model on your own stack? Hand us {input, output} at /v1/afir/sign. There's zero routing and zero model change. Your existing output becomes signed inference.
SideCar details → Best for: teams that can't change their inference path but need the signed record.
AFiR signs the whole output. AFiR-S signs the fragments that carry liability. That's the tool calls, the PII, the dollar figures, the decisions, and it binds an absence proof over everything it deliberately left unsigned. One ML-DSA-65 signature covers a Merkle bundle of the selected spans, so signing cost stays O(1) no matter how many spans there are.
AFiR-S signs. It does not infer. It is a read-only notary over output Hive did not generate. The choice of what to sign, and what not to, is itself on the record.
Selected spans are hashed into a Merkle bundle and committed under a single ML-DSA-65 (NIST FIPS 204) signature. Per-span signing was measured roughly 10× slower. The single-bundle commitment is the inventive core. hash_alg: sha-256 at the edge.
Every non-material span is hashed and bound into the same signature as an absence record. A verifier can prove a fragment was deliberately left unsigned. You cannot quietly drop or alter what was not selected.
The exact policy, presets and custom rules alike, is committed inside the bundle as policy_version. Verification is fully offline: no callback, no Hive API key required to confirm what was signed and why.
Default policy auto-selects tool calls and PII. Add a custom rule like INV-\d{6} to sign only invoice IDs. Everything else is recorded absent in the same signature.
AFiR-ARSC describes a risk-based signing and aggregation policy. Retrieval-grounding statements are signed inline; other captured fragments can enter an aggregate signed off the critical path. A signed citation binding records the supplied source relationship. It does not establish that the model read that source, and local signing is not blockchain finality.
The policy pins grounding events to inline signing. Deferred aggregation and any optional chain anchoring require separate evidence and deadline checks. The animation illustrates this policy, not a production acceptance test.
Retrieval-grounding and value-moving statements are assigned to the inline-signing tier. The intended policy prevents load-based demotion of grounding events. Acceptance requires checking the signed policy, classification inputs, captured fragments and deadline outcomes; a signed policy alone does not prove enforcement.
Retrieval→claim bindings and value-moving statements. The policy calls for inline ML-DSA-65 signing before returning the answer. This is a signing boundary, not block inclusion or finality.
PII, dollar figures and decisions. The policy commits their hashes before action, then signs an aggregate off the critical path. Hash commitment, aggregate signing and optional anchor inclusion are separate events.
Re-ranking tie-breaks, formatting and declared exclusions. The policy places hashes in a deferred batch. An exclusion declaration does not establish complete capture; any later chain anchor needs an inclusion proof and an observed status.
Tier is a live function of risk(f), the fragment's attested economic and epistemic risk, and load(t), measured from inflight signing depth. The elastic batch window W(t) shrinks under load so batches close sooner, and grows when idle so anchors are rarer and cheaper.
The scoring policy Π is committed and signed at session start and bound into every receipt as policy_hash + policy_sig. This is the anti-gaming control: a verifier recomputes the tier from the signed policy and confirms it matches what shipped.
A verifier needs a trusted issuer public key, the signed policy and its inputs, and the fragment-to-root proof. Root consistency does not establish anchoring: also check the root-to-transaction binding, chain ID, successful block inclusion, observation time and required finality policy against settlement_deadline.
Signing creates a signature over a defined statement. Submission acknowledgment means a service accepted a request. Preconfirmation is an early assurance under a named provider's conditions. Block inclusion requires evidence that the transaction succeeded in a specific block. Finality requires the chain's stated finality criterion at an observed time. None of these stages silently establishes the next.
A USDC payment does not prove that a receipt was anchored. Check the exact receipt digest, its inclusion path to the signed root, and the root's binding to transaction calldata or a contract event. Retain the chain ID, contract and transaction identifiers, block hash and height, success status, observation time and finality policy. Without that package, the anchor status is not established.
Signature validity, trusted issuer identity, consistency with a supplied root, inclusion under a trusted checkpoint, log consistency over time and tested durability are separate checks. A Hive-operated second signer is not an organizationally independent witness.
Publication note, September 5, 2026: AFiR SPICE draft-00, sections 3.2, 3.3 and Table 2, still describes approximately 7ms anchoring or on-chain confirmation. Those claims are not established by the evidence on this page. A correction proposal is pending external submission; the published draft has not been revised by this website update.
"arsc": { "policy_hash": "<sha-256 of signed scoring policy Π>", "policy_sig": "<ML-DSA-65 over Π at session start>", "fragment_tier": "T1", "risk_score": 0.90, "load_at_capture": 0.20, "grounding_pinned": true, "settlement_deadline": "2026-06-19T00:00:00Z", "aggregate_root": "<merkle root of T2/T3 batch>", "super_batch_id": "<one anchor per N queries>" }
A served inference call pays two costs at the gate: a clearance check (governance, jurisdiction, policy) and the establish/compute cost. In a cold FIFO queue that call sits idle, then pays both when its turn comes. AFiR-Hayes converts the otherwise-wasted wait into completed work. It runs the call's own clearance during the wait, finds its structural-reuse match, and pre-warms its likely route. When a legitimate re-ordering window opens, whether a batch boundary, a routing decision, or a fault or caution period, the calls that are already ready take the open lane. Every advancement is signed and attributable to that call's own productive wait.
The hard discipline: the only variance AFiR-Hayes introduces touches a call's own readiness. It never delays, degrades, contends with, or alters another call. A call advances because it was ready, not because another was held back. That limitation is claimed deliberately, and it is what keeps Hive a provenance provider rather than a scheduler exploit.
It is not an accelerator. Hive does not speed up compute, own GPUs, or change the model. The electrons run at the hardware's speed.
It is not queue-gaming. It does not induce contention, manufacture stalls, or degrade other calls to advance its own. That would destroy provenance and is excluded by definition.
It is the legitimate use of a call's own idle wait to remove that call's overhead from the critical path, plus the right to take an open lane when the system's own rules re-order the queue.
| Load (utilization) | Baseline p50 | AFiR-Hayes p50 | Latency gain | Pre-clear hit rate |
|---|---|---|---|---|
| 0.50 | 99 ms | 93 ms | 5.9% | 82% |
| 0.70 | 141 ms | 105 ms | 25.6% | 83% |
| 0.85 | 221 ms | 137 ms | 37.9% | 85% |
| 0.95 | 673 ms | 162 ms | 76.0% | 86% |
Simulated over 5,000 calls through a single gate, sweeping load. The Hayes effect is isolated from Structural-Lateration's compute savings (a separate, additive claim) and charged for speculative work on abandoned calls. Pure pre-clearance is bounded by clearance's share of service time (about 12 to 18% here); gains above that come from ready calls advancing through congestion, never from making any single call's compute faster.
If the call's inputs and policy are known while it waits, its Imprimatur clearance check runs during the wait and is signed. At the gate, clearance cost is ~0 because it is already done.
If the call's structural shape matches a known shape, the Lateration match is found during the wait so reuse is an instant lookup. The most-likely-cleared Stream-Route path is warmed so the call commits the instant the window opens.
Pre-clearing a call that is later abandoned wastes that work. AFiR-Hayes exposes a budget knob: it pre-clears only when sufficient idle wait exists and abandon-probability is low, and it reports wasted-speculation in the receipt, so the cost is provable, not hidden.
AFiR-Hayes is an orchestration enhancement over primitives that already exist. It adds nothing to the signed-primitive family; it removes waiting from the critical path.
Every AFIR receipt carries an smsh field. It's a cryptographic seal over the exact reasoning state (system prompt, context window, policy snapshot, identity) that was active when each fragment was signed. Without it, you can prove the output was signed. With it, you can prove the reasoning that authorized it. AFIR ships three SMSH tiers.
Drop AFIR into any OpenAI-compatible workflow with a single base URL swap. Native endpoint also available.
Works with Anthropic, Google Gemini, Groq, Mistral, or any provider with an OpenAI-compatible /chat/completions endpoint. AFIR owns decomposition. You supply execution.
Pick the product that matches your compliance posture. Same API for all four, swap by changing one header. Metered per receipt. Mint a key and start in minutes.
These are list rates, the Build column. Every tier earns the same volume discount as you grow (Scale −10%, Platform −20%, Hyperscale −30%). See the full signature × volume matrix. Usage is metered and uncapped: no monthly minimum, no ceiling. You pay for exactly what you sign and verify.
High-volume commits, dedicated signing-key infrastructure, white-label receipts, on-premise Docker, and partner-resident deployment inside your perimeter are negotiated directly. Talk to Steve
Explore modeled costs and latency using the page's configured rate and workload assumptions. These are not executed benchmarks, current price quotes or measured savings.
Illustrative model with June 2026 rate assumptions and a 0.99ms signing assumption. No paired inference or verification runs execute when sliders change. Cache behavior, failures, retries, selector work, extra candidate inference and complete compute costs are not measured. The latency calculation models a critical path, not total compute time.
All four panels are modeled. Receipt counts and signing overhead are fixed assumptions, not evidence that receipts were issued or verified.
Enter your Together, Fireworks, or custom provider numbers. See the signed-tier margin and latency gap side by side.
Open Inference Comparator →The objections engineers and legal teams raise. Answered with numbers, not marketing.
Latency reduction depends on query type. Simple queries bypass decomposition entirely (gate bypass) and complete in 352ms vs 1,692ms for a monolithic GPT-4.1 call, about 4.8x faster. Complex queries run fragments in parallel, and wall-clock time tracks the critical path, not total token count. In live benchmarks with the edge lane (Cloudflare Workers, signed at edge), signed model first token median is 112ms (p90 145ms, under 150ms). Everyone fast on the leaderboard is unsigned. We sign at that speed. Perceived first byte median 59ms. Cost: $0.000029/response, about 8x cheaper than Together ($0.000228), all signed. Cheaper models account for cost savings, and parallelism accounts for latency savings. These are separate gains. The tiered routing cuts the bill. The DAG execution cuts the latency.
The implementation work includes dependency-aware decomposition, endpoint-specific signatures, receipt-to-root inclusion and key custody. The reported 0.99ms signing median is not an end-to-end guarantee. DAG correctness, capture completeness and custody must be tested for the deployed integration. Customer-held signing keys are a deployment option, not a property established for every hosted route.
Signing outputs at the final response layer is not new. What is patent-pending (filed June 2026) is the combination of fragment-level attestation across a routed DAG. Specifically, we attest each node before its output is consumed as input by a downstream node, so the chain of custody is continuous and not retrospective. Prior art signs the envelope. AFIR signs every edge in the dependency graph mid-execution. If you have specific prior art that covers per-node attestation within a runtime inference DAG with Merkle assembly proofs, file it against the application. That is the correct venue.
The signed receipt captures the exact input state, the routing decision, the full dependency graph, and the output hash at assembly time. If assembly produces an incorrect result, the receipt is forensic evidence of exactly which node produced which output under which routing decision. That is the point of the Merkle completeness proof. Liability follows the evidence: if the decomposition logic is wrong, that is traceable to the DAG construction step in the receipt, and if a model tier returns a defective fragment, that is attested at that node. Hive provides the receipt infrastructure and the routing logic, and the customer's signed key binds them to the input state they submitted. The receipt does not resolve liability by itself. It makes the facts unambiguous.
Key custody is deployment-specific. A customer-held signing configuration requires evidence of key location, access controls, signing authorization, export policy and recovery tests. This page does not establish that hosted-route keys stay inside a customer's perimeter or that Hive lacks signing authority. Hosted routing can transmit inference payloads outside the customer's network. Review the deployed architecture and data flows against your legal and security requirements.
The EU AI Act's current logging obligations for high-risk systems do not mandate per-fragment attestation or Merkle assembly proofs. AFIR's receipt format exceeds those requirements by design, not by regulatory necessity. The value here isn't compliance box-checking. It's that when a regulator, customer, or internal audit asks exactly what inputs produced exactly what output under exactly what model routing decision, you produce a cryptographically verifiable answer rather than reconstructed logs. Regulations are a floor, and your exposure in a dispute is the ceiling. The receipt is for the ceiling.
Audit logs record what your system observed. Receipts attest what the inference system executed. Your logs can be amended, retroactively structured, or missing entries due to pipeline failures. They're assertions your system makes about itself. An AFIR receipt is signed at execution time by a key you hold, binds the input hash, the routing graph, and the output hash into a Merkle structure, and cannot be back-filled without invalidating the signature. The distinction matters when a counterparty, whether a regulator, a plaintiff, or an enterprise customer, challenges whether a specific output came from a specific input under a specific model. A log entry is testimony. A receipt is evidence.
Offline verification can survive service unavailability if the supported receipt bytes, trusted public-key history, required proofs and verification software have been retained and tested. Availability, issuer-key history and recovery are separate from signature validity. Customer key custody, escrow and export procedures depend on the actual deployment and executed agreement; no such agreement or recovery evidence is supplied here.
Illustrative architecture, subject to an executed deployment agreement and configuration tests. Confirm payload routing, key custody, activation traffic, countersigning and recovery before claiming that data or signing authority remains inside your network.
Available to Hyperscaler tier customers. Submit your request and we will follow up with deployment specs, image delivery, and licensing terms.
One checkout. Your live key appears on screen the moment payment clears. No email round-trip, no waiting. Metered billing: you only pay for what you sign.