That is Harness's own finding. In State of AI in FinOps 2026, published July 29, 2026, Harness reports that spend is "climbing fast and broadly, across every category and provider at once, while the ownership, visibility, and governance structures needed to manage it haven't caught up." Harness is already the platform closing that gap: Cloud & AI Cost Management delivers unified spend visibility, attribution, governance, and optimization, wired into the engineering workflow rather than bolted beside it. This brief proposes one addition next to it. An independent signed receipt at the level of the individual run or unit of work, so a charge can be tied to the work that created it and the evidence still stands later. Every demo on this page runs in your browser, apart from the live workflow, which is labelled where it calls the Hive API. No prompt, source, secret, or artifact content ever crosses to Hive.
The proof is in the provenance. It does not judge.
Harness surveyed 700 engineering leaders and practitioners across five countries in May and June 2026 and published the result on July 29, 2026. These are Harness's figures, not Hive's. Hive draws no conclusion about Harness beyond what the report itself states, and readers should re-verify the report before any external use.
Read together, the two describe a visibility and attribution problem rather than an intent problem. Teams want to answer where a charge came from and whether the work behind it was worth the money. The awkward part is that the answer has to keep holding later, in front of finance, an auditor, a procurement review, or a customer asking why a bill moved two quarters ago.
Harness Cloud & AI Cost Management already gives teams one place to see spend across every AI provider and managed service, token and inference visibility by agent, model, and team, full spend attribution, anomaly flagging before the invoice lands, and budgets at the agent, team, or business unit level. That is the operating layer and it belongs exactly where Harness put it. A receipt is doing a different job, in a different tense.
Nothing here suggests a platform's own reporting is wrong. The point is narrower and more practical. A figure computed inside a system is a statement by that system, and there are rooms where a party wants evidence that does not depend on trusting the party presenting it. A signed receipt is that evidence, and it is additive to the number the dashboard already shows.
The receipt does not change how any of these surfaces work and does not sit in front of them. It attaches beside the surface and records what happened, so the result stays checkable after the window closes. Source, prompts, secrets, artifacts, and findings stay inside the Harness and customer boundary throughout.
Perspectives group resources by what matters to the business, Cost Categories attribute data across sources to business contexts, and AI Cost Management traces spend to the agent, session, workflow, team, and business unit driving it. A receipt adds a signed record for the individual run, so a line inside a Perspective can be tied to the specific request that produced it.
Harness CI builds and pushes artifacts, Harness CD runs canary and rollout strategies with AI Verify, and Harness AI agents run inside pipelines from commit to production. A receipt attaches at the stage, binding which step ran, under which approval, and what it consumed, so the spend record and the delivery record are the same record.
Harness applies OPA policy-as-code on save and on run, and Asset Governance manages cloud environment and spend through governance rules and budgets. Harness reports 73% of organizations have AI cost policies while 47% fully enforce them. A receipt records which policy evaluated, on what, and the result, producing portable evidence a control reviewer can check.
Anomaly Detection identifies unusual or unexpected changes in cloud service expenses, and AI Cost Management flags spend spikes before they hit the invoice. Harness reports 79% of organizations need a full day or longer to trace a spike to its source. The receipts covering that window let an investigator narrow to the runs whose signed cost basis matches the movement.
BI Dashboards turn cloud data into modeled and visualized metrics, and Perspectives create tailored views for engineering, finance, or leadership. A reported figure backed by receipts can be re-verified offline against the signed set underneath it, by a reviewer who never had access to the platform that produced it.
A large share of AI spend is ordinary requests a person wrote, from an IDE, a support console, an internal tool, or a notebook. The rail treats a human-composed request and an autonomous agent step the same way, because the cost lands in the same place and the attribution question is identical. Nothing here requires an agent framework to be present.
Every Harness capability named above is public and first-party source-linked in the evidence section below, current as of July 2026, and should be re-verified before external use. This is a proposed architecture, not a description of anything Harness has deployed.
Left of the line is everything inside the Harness and customer boundary. Right of the line is a finance reviewer, an auditor, a customer, or a downstream team. Watch what actually crosses.
Every square that crosses is a receipt, not a copy. The count of prompt, code, secret, and artifact bytes that crossed is always zero. That is the whole design.
Sliders are yours to set. This is arithmetic on numbers you enter, not a forecast, a quote, or a claim about Harness's real volumes.
Whatever you put in those sliders, the last number is always zero. Proof bytes scale with the number of runs; content bytes moved do not scale at all.
This widget builds a real signed receipt for a Harness deployment action, verifies it in your browser, lets you tamper with a byte and watch the check fail, re-verifies from pasted JSON, and re-checks a published 5,000-frame routine soak. The signing engine is bundled and served from this same domain. Open your network tab: after load, it makes zero outbound calls except the two same-origin JSON fetches it names.
In-browser · offline The offline verifier never leaves this page except to fetch its own sample and bench file from this domain.
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. The same engine ships as an offline command-line kit that is byte-identical to what runs here.
Four mechanics inside the InkFrame v1 receipt frame, exercised by the verifier above. These are frame mechanics. They are not the four filed primitive families, which are set out further down this page.
This is a self-contained simulator that behaves like a small Harness delivery pipeline: build, test and security scan, approval and policy gate, deploy and canary, verify and rollback. Each stage produces a visible signed proof state, and the whole run folds into a final evidence bundle you can export. It runs deterministically in this tab and calls no Harness API, so nothing depends on an account or a login.
In-browser · deterministic The simulator runs a fixed, Harness-shaped pipeline locally. Source, artifacts, and deployment payloads are hashed into each stage receipt; the payloads themselves never cross to Hive.
The two tamper buttons show the two failure modes that matter in delivery: an artifact swapped after the gate, and a canary weight that breaks a stated policy. In both cases the mismatch is caught visibly and the signed evidence refuses to line up. Success and failure are labelled PASS or FAIL, never color alone.
This is different from the offline verifier and simulator by design. It drives the real Hive receipt primitives in a Harness-shaped sequence: relay a signed deployment event, group it into a proof vector (R3Pv), run a Protected Flow assessment under a strict delivery policy pack, and export a signed evidence bundle. No account, no key, no payment beyond the calls you trigger. No deployment payload moves and Hive never calls a Harness API.
Network state: unknown This leaves your browser and hits receipts.thehiveryiq.com. If the call is blocked by CORS or offline, the widget runs a truthful local cryptographic fallback and labels it clearly. It does not fake a live success.
The Harness-shaped payload carries a deployment event kind and strategy only, never source code or a secret. Curl the same sequence yourself:
These are the four families Hive filed on July 31, 2026, each defined on Hive Proof Architecture and used here exactly as defined there. All four apply to an autonomous agent step and to an ordinary request a person composed, without distinction between them.
For a spend conversation, the pairing that does the work is MSDD and BPA. A provider's reported token count, duration, or unit cost is carried as a provider assertion and labeled as such, sitting beside what Hive separately observes at the delivery boundary, in one structure, with neither value overwriting the other. Foretoken™ makes the run itself impossible to reconstruct favorably afterwards, and Stipryn™ lets the team that will carry the cost decide how much proof a class of request needs before it is sent, without touching the request.
Hive is not omniscient about a system it does not run. Every value inside a receipt carries the basis it came from, and the three bases stay separate on purpose. Nothing in the structure quietly promotes one into the other.
The things Hive does not do are worth saying out loud. Hive does not read prompt, response, source, or artifact content; each is recorded as a one-way SHA-256 fingerprint. Hive cannot see inside the Harness platform and makes no claim to. Hive does not judge whether an answer was good, whether a spend was justified, or whether a control satisfies a regulation. A signed record that a policy was checked is a record, not a compliance statement. What Hive offers is a structure a party can check without having to trust the party that produced it.
The proof step is fail open by default. If the pre-commitment or the signing step is slow, degraded, or unavailable, it does not hold the run, the request, the build, the deployment, or the response. Harness continues operating exactly as it does today, and the work completes whether or not a receipt was written for it.
This is the property that makes a POC cheap to try and cheap to abandon. The downside of switching it on is bounded, and the artifacts produced during the trial keep their value even if the answer is no.
Organized around the same six surfaces the map above names. Everything under Running now is live today, and the verifier, simulator, and live workflow on this page exercise it. Everything under Expansion offerings is a surface Hive could stand up with Harness, not a service running yet. The distinction is kept explicit so nothing on this page reads as further along than it is.
The InkFrame v1 receipt frame is the fastest path in. Hive Proof Architecture is broader than that. This is the whole map, kept on this page so nothing needs to be chased down elsewhere: each primitive, the Harness surface it fits, what it does now, and what it could do next.
| Hive primitive | Harness surface | State | What it does |
|---|---|---|---|
| Foretoken™ | Cloud & AI Cost Management · everyday requests | Filed · expansion | Commits to a run before or at the same moment the first streamed content leaves the model, carries an incremental digest as content flows, then seals a terminal attestation tied back to that opening commitment. Filed July 31, 2026. |
| Stipryn™ | Policy and governance · everyday requests | Filed · expansion | Fixes the required proof level before transmission, while the party bearing the consequence still controls the request. It analyzes and binds; it does not change the request. Filed July 31, 2026. |
| MSDD | Cloud & AI Cost Management · reporting | Filed · expansion | Binds what a provider asserts and what is separately observed into the same structure, without merging them into a single reconciled value. Filed July 31, 2026. |
| BPA | Anomaly investigation · reporting | Filed · expansion | Binds a declared performance budget and the performance that actually occurred to the same response content. Filed July 31, 2026. |
| InkFrame v1 | All surfaces | Running now | The signed receipt frame: content-addressed roots plus a hybrid Ed25519 + ML-DSA-65 signature. The verifier above builds and checks one. |
| Proof Pre-Fill | Cost management · pipelines | Running now | Frame mechanic A. The receipt is attached at the moment of the step, so it adds no delay to a run, a build, or a deploy. |
| InkFrame Non-Mutation | Anomaly investigation · pipelines | Running now | Frame mechanic B. One changed byte fails the check. This is the tamper test in the verifier and the simulator. |
| Disclosure-Free Replay | Reporting · anomaly investigation | Running now | Frame mechanic C. Reconstruct the route a run took from fingerprints alone, with no prompt, source code, or artifact. |
| Arrival Countersignature | Policy and governance · reporting | Running now | Frame mechanic D. The gateway countersigns on arrival, so what arrived is what was cleared. |
| Receipt Relay | Cost management · pipelines | Running now | Signs an event into a portable receipt. Step 1 of the live workflow above. |
| R3Pv proof vector | Pipelines · policy and governance | Running now | Groups signed receipts into one signed vector: verification, policy, healing, routing, and permitted next action. |
| Protected Flow | Policy and governance · pipelines | Running now | Turns the vector into a signed decision (permit, hold, recover, escalate) under a policy pack, with a meter quote. No payload moves. |
| Evidence Export | Executive and audit reporting | Running now | Bundles the vector, assessment, receipts, and pubkeys into a signed bundle a reviewer re-verifies offline. |
| Carnac™ | Everyday requests · pipelines | Running now | Sizes how much proof an action deserves. It does not judge. |
| CarnacPrompt™ | Everyday requests | Running now | Fingerprints the request as a one-way SHA-256, never the words. |
| Carnac Gateway™ | Everyday requests · pipelines | Running now | The gateway that countersigns request and pipeline traffic on arrival. |
| Carnac Live Ink™ | Everyday requests · pipelines | Running now | Live-streamed proof ink for an in-progress run, sealed as it runs. |
| SmartAgent route proof | Pipelines · everyday requests | Expansion | Proof for multi-step behavior across a workflow route. |
| Protected Flow Fleets | Pipelines · cost management | Expansion | Fleet-scale protected-flow decisions across many concurrent runs. |
| AFiR-Stream™ | Cloud & AI Cost Management | Expansion | Streaming receipt proof for high-volume run batches. |
| OriginProof | Pipelines · reporting | Expansion | Origin attestation for build artifacts, SBOMs, and security findings. |
| PPR · SRPR | Executive and audit reporting | Expansion | Provenance and settlement receipts for released artifacts. |
| Sovereign Receipt Registry | Enterprise · audit | Expansion | Jurisdiction-held or customer-held receipt registry. |
| Provable Machines | Pipelines · policy and governance | Expansion | Build-time control-execution receipts for pipeline runs. |
Running now rows are exercised by the verifier, simulator, and live workflow on this page. Filed rows are the four primitive families filed July 31, 2026; patent pending, and a filing is not a granted patent. Expansion rows are options to weigh with counsel and with Harness's engineering, finance, and security functions; none of them is a live service today.
These are Harness's own words and docs, public as of July 2026. Hive draws no conclusion about Harness beyond what these state, and does not imply Harness is a customer, partner, or endorser. Every figure quoted anywhere on this page comes from one of the first two sources below.
Choose a single surface from the map above and name it. Per-run attribution inside Cloud & AI Cost Management is the shortest path, and one pipeline or one anomaly investigation works just as well. Hive builds the evidence layer for that one surface and publishes the verification path. Harness stays the source and custodian of everything inside its own boundary throughout, the proof step stays fail open, and the whole thing can be removed without leaving anything behind.
This is a private prospect artifact from Hive Civilization Inc. Harness is not a customer. Nothing here implies a partnership, endorsement, deployment, agreement, or customer relationship. Foretoken™, Stipryn™, Multi-Source Divergence Detection, and Bonded Performance Attestation are patent pending, filed July 31, 2026. A filing is not a granted patent. Harness product facts and report figures referenced on this page are public, first-party, and current as of July 2026, and should be re-verified before external use.
Both of these are newer than the rail described above. They are code complete and not yet deployed, and the runs below say so on their face. They are here because a Harness reviewer looking at spend attribution and budget policy will want them next.
A cost spike almost never has one receipt. It has a chain: a request came in, a model was picked, a build ran, an artifact shipped. This receipt takes a list of receipts you already hold and proves the chain is continuous, output digest to input digest, step by step, from a named origin to a named terminus. If any link is missing or swapped, the check fails and names the index where it broke. You get one artifact that says the whole path holds, instead of a folder of receipts a reviewer has to trust you assembled honestly.
What it does not do. It does not say the spend figure is correct, does not say any step was the right thing to do, and does not reveal any prompt, source, artifact, or payload. It proves only that the digests line up in the order claimed.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
A budget rule written after the overspend is an argument. A budget rule committed before the window opens is evidence. This receipt binds a threshold to a time, then checks the ordering: the policy was committed, then the budget was declared, then the measurement window opened. When the measured value crosses the line, the receipt records that it did and that the rule predated the measurement. When it does not cross, that is recorded too. Both outcomes are valid receipts.
What it does not do. It does not measure anything itself, does not decide who pays, and does not enforce a stop. It records that a specific rule existed before the thing it judged, and what the comparison came out to.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
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.
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.