prepared privately for Kodiak Robotics · not indexed

The Kodiak Driver already knows what it did. Hive lets you prove it.

The Kodiak Driver is a virtual driver that perceives, plans, and acts across a driverless truck. When a single consequential driverless action is later reviewed, the record of it lives in the same stack that produced it.

Hive comes alongside that stack as a sidecar. It adds an independent, signed receipt for each consequential driverless action, checkable by anyone offline. It never steers the truck, never alters the autonomy stack, and never moves your proprietary sensor data.

20 driverless trucks
operating fully driverless, described by Kodiak as the world's largest deployment of customer-owned driverless trucks
Kodiak AI, Q4 2025 results
10,700+ hours
cumulative hours of paid driverless operations, a 106% increase from the end of the prior quarter
Kodiak AI, Q4 2025 results
360° SensorPods
house LiDAR, radar, and cameras for full surround coverage and are field-swappable in minutes
Kodiak Driver technology
daily releases
of the driving software, each tested in simulation and structured on-road tests before it reaches a truck
Kodiak Driver technology

Three simple states

Where a driverless action record is now, where a signed receipt takes it, and what stays yours.

● today · current state

You can show your logs

When a regulator, an insurer, an incident reviewer, or a fleet customer questions a specific driverless maneuver, you look it up and explain it from your own logs. Useful, but the record is controlled by the same stack whose action is in question.

● with Hive · sidecar state

You can hand over proof

Each consequential action gets an independent, signed receipt made at the moment it happened: which perception input and software version applied, what policy cleared it, what the truck did, and whether the record moved afterward. Anyone can check it offline.

● travels with the run · portable

The receipt goes with the safety case

The signed receipt can travel with an incident review, a safety case, an insurer packet, or a customer discussion. The evidence is built the moment of the action, not reconstructed under pressure weeks later.

follow one driverless action · synthetic data · runs in this tab

Follow one driverless action from perception to a signed receipt

Pick a driving situation. The truck perceives, a software version and a policy apply, a plan is authorized, the truck acts, and a signed receipt is made and folded into a run bundle. Nothing here is real Kodiak or sensor data. It is synthetic, made to show how the sidecar works. Hive never steers the truck.

● what a log shows today
● what a signed receipt adds
Signedanyone can check it

Press Run this action to watch the receipt get stamped and folded into a run bundle.

offline verifier · runs entirely in this tab · no telemetry after page load

Check a receipt yourself. No install.

This builds a real signed receipt for a driverless action, checks it in your browser, lets you break one byte and watch the check refuse it, re-checks pasted evidence, and re-verifies a published 5,000-receipt soak test. Everything runs in this tab.

The signing engine is bundled and served from this same site. After the page loads it makes zero outside calls except two same-site file reads it names out loud.

In-browser · offline The verifier never leaves this page except to read its own sample and soak-test file from this site.

Idle. Click 1 · Build & check a receipt to load the engine and run the first check. Everything runs in this tab.

Every click prints the recomputed hash next to the stored hash, one line per layer. A changed byte reads FAIL in the same output; a clean receipt reads PASS. Success is labelled, never color alone. There is no server round-trip.

route run safety-case bundle · deterministic · runs in this tab

Assemble a run's evidence, then seal the bundle

A driverless run is a sequence of consequential actions. This compact demo takes three signed actions from one synthetic run, rolls them into a single grouped proof vector for the whole run, folds it into a signed bundle, and lets you change one action after signing to watch the check refuse it. All values are synthetic.

action 1 · lane change
run id · SYN-RUN-4471
software · driver-build v8
policy · merge-clearance-v3
result · cleared, executed
action 2 · hard brake
trigger · cut-in ahead
software · driver-build v8
policy · collision-avoid-v5
result · cleared, executed
run rollup
actions sealed · 3 of 3
weakest link · none flagged
state · recoverable
raw sensor bytes · 0
Idle. Press Assemble and seal to roll the run's actions into one grouped proof vector and fold it into a signed bundle.

This is a grouped proof over synthetic actions folded into a real signed frame, not a Kodiak run and not sensor data. The rollup names the weakest link for review; it does not judge the maneuver.

your numbers · arithmetic tool, not a forecast, quote, or ROI claim

Move the sliders. See evidence volume and time you stop reconstructing.

This is an evidence-coverage tool. It counts how many signed receipts a given fleet's driverless activity produces and how much reconstruction time signed coverage can remove. Every value below is a number you set. It is not a forecast, a quote, or a dollar-savings claim.

Every slider is yours to set. This is arithmetic on numbers you enter, not a forecast, a quote, or a claim about Kodiak's real fleet activity.

Signed receipts / hour of operation·
Signed receipts / 10 operating hours·
Reviewed actions covered by a receipt·
Reconstruction hours avoided
covered actions, no manual rebuild·
Raw sensor bytes moved to Hive0 bytes

Whatever you enter, the last number is always zero. Receipts carry one-way fingerprints and commitments, never raw sensor data. Evidence volume scales with actions; proprietary sensor data moved to Hive does not scale at all, because it never moves.

Where this fits Kodiak's stack

The same signed receipt fits many parts of the Kodiak Driver's surface. Here is where it earns its keep, in plain words. Kodiak's capabilities named below are drawn from Kodiak's own materials, linked at the foot of the page. Hive sits alongside, never inside the control loop.

Perception, planning, and the driving software
Kodiak Driver software versionWhen a driverless action runs, a receipt records the exact driving-software version that acted, so a daily release can be traced to the run it first affected without opening the stack.
SensorPod perception captureA perception input to a decision can carry a capture-side provenance receipt, so the frame a plan was built on is bound to the decision, as a fingerprint, never the raw sensor feed.
Plan and policy clearanceBefore a consequential maneuver runs, the policy it must pass is checked and the clearance is signed, so a later question about whether a control applied has a signed answer.
Multi-step perception-to-action pathA multi-step decision path is signed step by step, so a plan built from several perception and prediction stages is provable stage by stage.
Runs, incidents, and the safety case
Route and run rollupsThe consequential actions of a single run roll into one grouped proof vector, so a route can be reviewed without re-running the whole trip.
Incident and disengagement reviewWhen an incident or a disengagement is reviewed, a bundle of receipts becomes a portable evidence package that travels with the review, checkable by the other side offline.
Field monitoring and continuous improvementWhere Kodiak's Safety Management System monitors the field, each monitored action seals the version and policy it ran under, so a fix is traceable to the runs that motivated it.
Fleet-level proof stateMany runs across many trucks roll into one fleet view by route, customer, or software version, so proof state is readable at fleet scale.
Defense, industrial, and portability
Defense and industrial deploymentsWhere the Kodiak Driver runs in a defense or industrial vehicle, a signed receipt gives an independent, offline-checkable record of a consequential action, useful where a chain of custody matters.
Insurer and customer evidence packetsA bundle of receipts becomes a portable packet that travels with an insurer or customer discussion, checkable without access to your systems.
Hardware-rooted signingThe signing key can live in hardware on the vehicle or in the fleet, so a stolen key cannot forge receipts and the compute that ran the work is attested too.
Software, model, and version provenanceEvery outcome is pinned to the exact driving-software version that produced it, so a change in driving logic is traceable to the run it first affected.

What supports this behind the scenes

You do not need any of this to understand the value. It is here for the people who want to look under the hood. Each row is a plain benefit first, with the Hive part named as a small label.

A single driverless action becomes a signed exhibit: the perception input, the software version, the policy, and the outcome, sealed into one receipt. SiGR patent pendingSiGR →
SiGR, the Signed Inference Guarantee Receipt, signs a model or automation decision into one receipt anchored on Base. It turns "trust our logs" into a signed exhibit that stands up in an incident review or a customer discussion. See the SiGR page.
The policy or clearance is checked before the maneuver runs, and any action without a valid pass is refused. Imprimatur patent pendingImprimatur →
Imprimatur is a pre-action attestation gate. It signs a clearance before a consequential action runs and refuses any call without a valid, unexpired pass, so "the control was enforced" is proved up front rather than reconstructed after the fact. It sits alongside the stack and never enters the truck's control loop. See the Imprimatur page.
Many receipts from one run or route roll into a single grouped proof vector that flags the weakest link. R3Pv patent pendingR3Pv →
R3Pv, the Receipt Proof Vector, groups receipts into one signed vector: verification depth, weakest boundary, recoverability, and next action. One machine-readable summary per run or route lets a review team triage instead of re-checking everything. See the R3Pv benchmark.
Every outcome is pinned to the exact driving-software version that produced it, and whether it passed its checks. MiR · SPIRE patent pendingMiR →
MiR, Model Identity and Relineage, signs which model actually served each step, and detects substitution against the model you contracted for. SPIRE adds a signed identity for the vehicle instance and its trajectory. A change in driving logic is traceable to the exact run it first affected. See MiR and SPIRE in the proof architecture.
Big perception jobs and multi-step plans get proof at the piece level, without re-running the whole thing. AFiR · AFiR Stream patent pendingAFiR →
AFiR, Attested Fragmented Inference Routing, breaks a request into signed, routable sub-tasks and signs each fragment inside the path, so a multi-step perception-to-plan decision is provable step by step. AFiR Stream extends this to real-time telemetry and streaming inputs, signing evidence as it flows. See the AFiR page and AFiR Stream.
A perception input from a SensorPod carries a capture-side provenance receipt, so the frame a plan was built on is bound to the decision. PPR · M.O.R. patent pendingPPR →
The Physiological Provenance Receipt attests capture-side sensor provenance, so a signal is bound to the sensor and moment it came from, as a fingerprint rather than the raw feed. Media Origin Receipt (M.O.R.) does the same for camera frames, attesting where an image originated. See the PPR page and Media Origin Receipt.
A typed perception or plan fragment is signed with its type, so the shape of what was signed is unambiguous. Typed Signer patent pendingTyped Signer →
Typed Signer is the ML-DSA-65 signing core that binds a typed fragment to its schema, so a signed plan or perception field cannot be reinterpreted as something else. See the Typed Signer page.
Fleet-wide, many runs become a recoverable, reviewable proof state instead of just lines in a log. Protected Flow Fleets · Provable Machines patent pendingFleets →
Provable Machines is the robotics and machine-work proof vertical for signed physical actions, and Protected Flow Fleets rolls many receipts into one proof-state view by route, customer, or software version. See Provable Machines and Protected Flow Fleets.
The signing key is born random and lives in hardware, so a stolen key cannot forge your receipts, and the compute is attested too. HiveSeal · QPuF · S2S patent pendingHiveSeal →
HiveSeal with QPuF is a hardware root of trust: a signing device that keeps the key in silicon, born from quantum-grade randomness and bound to the device. S2S adds hardware-rooted attestation of the compute that ran the work. See the HiveSeal page and S2S.
Under it all sits the evidence floor that holds a decision still while proof is attached, so it can be rebuilt and re-checked offline. InkFrame v1 · Carnac™ family patent pendingInkFrame →
Carnac™ sizes how much proof an action deserves, CarnacPrompt™ carries the human-visible context and proof demand, Carnac Gateway™ clears an action before it runs, and Carnac Live Ink™ writes non-mutating evidence frames. InkFrame v1 holds a proof-completion frame still using eight content-addressed roots and a hybrid Ed25519 with ML-DSA-65 signature. Change one byte and the address changes, which breaks the seal. See InkFrame v1, the Carnac™ plane, CarnacPrompt™, Carnac Gateway™, and Carnac Live Ink™.

Explore Hive Proof Architecture.

The keys stay with you

In plain words: your organization holds the pen that signs. Hive never touches your proprietary sensor data, never steers the truck, and never holds your keys.

You hold your own signing keys

You keep the private key that stamps your receipts. Nobody else can sign in your name, and the key never leaves your own hardware. The signature is yours, not Hive's.

Hive stays a non-custodial sidecar

Hive gives you the way to make and check receipts. It does not steer the truck, does not alter the autonomy stack, does not enter the control loop, and it does not move or store your raw sensor data. Each action is recorded as a one-way fingerprint and cryptographic commitment, never the underlying feed.

Turn a driverless action into a portable trust asset

As driverless deployments scale, an incident reviewer, an insurer, or a fleet customer will ask what a truck did and why. A signed, independently checkable receipt for each consequential action is how autonomy stays defensible. Naming this does not imply any agreement, and this page does not state or imply that Kodiak is a customer, partner, pilot, or endorser.

Engineering & Autonomy Safety & Systems Risk, legal & insurance

One line to start: [email protected]

Private overview prepared for Kodiak Robotics · noindex / nofollow / noarchive / nosnippet · this page does not state or imply that Kodiak Robotics or Kodiak AI, Inc. is a customer, partner, pilot, or endorser, and does not imply Kodiak uses Hive · the situations, runs, versions, and receipts shown are synthetic and made to illustrate how the service works; they are not Kodiak or sensor data · Hive is a sidecar; it does not steer the truck, does not alter the autonomy stack, does not enter the control loop, and it does not move or store raw sensor data · a signed record that a policy ran is not a statement of safety, roadworthiness, or regulatory compliance · Hive never reads the underlying feed; each action is recorded as a one-way SHA-256 fingerprint and cryptographic commitment, not the raw signal · Carnac™ sizes how much proof an action deserves. It does not judge. · verification is free, works offline, and needs no account · signatures use a hybrid of Ed25519 and ML-DSA-65 (NIST FIPS 204), a federal standard · Kodiak product facts referenced are drawn from Kodiak public materials (kodiak.ai/technology, Kodiak AI Q4 2025 results) current as of July 2026 and to be re-verified before external use · Carnac™, CarnacPrompt™, Carnac Gateway™, and Carnac Live Ink™ are Hive marks · all Hive methods patent pending · prepared by Hive Civilization Inc. · Wyoming, USA
new in the canon · runnable on this page

One receipt for the whole action, not one per step

The sidecar above signs a receipt for each consequential driverless action. This newer receipt does the next thing a reviewer asks for. It ties those receipts into one continuous chain so the sequence itself is provable. It is deployed and open to verify, so the run below is a live check, not a mock.

causal.path · Deployed in production

Prove the sequence, from perception to the action taken

A review of one driverless action is really a review of an ordered set of them. This receipt takes the receipts you already hold for a window and proves the chain is continuous: each step's output digest is the next step's input digest, from a named origin to a named terminus. Hand it to a regulator, an insurer, or the other side's expert and the ordering holds without anyone reading your sensor data. Break one link on purpose and the check fails and tells you which index broke.

What it does not do. It does not say the driving decision was correct, assigns no fault, does not interpret perception, and never moves LiDAR, radar, camera, or map data. It proves that the sequence you claim is the sequence the digests support.

Open the Causal Path Receipt pageCanon entrySchema
POST /verify/causal-path · case pass, a clean record

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

POST /verify/causal-path · case broken, the chain is broken

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

Every run above posts a verified request body from this domain to the open verify route and prints what came back. The example receipts are signed with published example keys, so verify reports key_trust example_registry. That is on purpose. Nothing on this page is a production issuance, a customer record, or an endorsement. Patent Pending.

Canon cross reference

The exact canon entries behind this page

Each link opens that entry in the canon implementation explorer, where its schema, mint route, open verify route, auth requirement and implementation state are stated. The state shown here is read from the same registry file the explorer renders from, so the two cannot drift apart. Nothing here implies a customer, a deployment or an endorsement.

Search the explorer for Kodiak Robotics proof surface