Hive is a provider facing proof layer. It takes timing data that already exists inside an inference call, plus any compute value or assertion the provider chooses to declare or sign, and turns both into a signed, tamper evident record.
Hive does not sit between Cerebras and its customers. It does not alter the model, the request, or the response. It marks clearly where wafer compute time ends and the surrounding network, proxy, load balancer, and client stack begins.
Additive, never load bearing. Cerebras keeps running exactly as it does today with or without Hive.
Cerebras has built its business on a wafer scale architecture that Cerebras positions as delivering industry leading inference speed. Hive's role is additive: independent, response bound evidence that travels alongside the speed Cerebras already delivers.
As inference architectures disaggregate further, including the direction described in the July 23, 2026 AMD and Cerebras announcement of a combined ultra low latency, high throughput inference workflow, that boundary spans more stages, and Hive can extend the same evidence across each one.
Hive does not sit between Cerebras and its customers, and does not alter the model, the request, or the response. It observes the delivery path and binds what it observes.
What Cerebras asserts, what a separate observer measured outside Cerebras's own reporting path, and what a cryptographic commitment locked in place before the fact. Never merged into one number.
If a Hive proof component is slow, unavailable, or removed entirely, Cerebras inference is unaffected and continues to serve responses. Any receipt already issued remains independently verifiable on its own.
Source for the disaggregated inference workflow: https://www.cerebras.ai/press-release/amd-and-cerebras-announce-industry-leading-ultra-low-latency-and-high-throughput-ai-inference
Four different things can be true about a single value, and collapsing them into one is exactly the kind of overreach this companion is written to avoid.
What the client asked for: the request content, and, where Stipryn™ is in use, the required proof level bound to that request before it was sent.
What Cerebras declares about its own execution: model version, silicon identity, declared latency, declared throughput. These values come from Cerebras and are carried in the receipt as Cerebras's own assertion, labeled as such.
What a Hive instrumentation layer times from outside Cerebras's own reporting path: delivery side timestamps on the request commitment, on each streamed content unit, and on the terminal seal. This is a measurement of delivery and instrumentation behavior, not a measurement of wafer compute time.
What a third party can check directly from the signed artifact, without trusting Hive's arithmetic and without access to either party's execution environment: whether the observed and reported values are internally consistent, whether the terminal attestation ties back to the pre commitment, and, where Cerebras signs its own assertion with a Cerebras held key, whether that signature validates against a Cerebras published key.
scope boundaryHive does not see Cerebras GPU or wafer internals. Hive has no visibility into the Wafer Scale Engine's execution, scheduling, or internal state. Any statement on this page about compute refers only to a value Cerebras itself declares or signs. Hive's own observation is limited to what happens on the delivery path outside Cerebras's execution environment.
A Hive receipt binds all three into one sealed artifact without merging them into a single reconciled number. A verifier does not have to trust Hive's arithmetic, because the commitment structure is checkable on its own.
Claims Cerebras makes about its own performance: silicon identity, model version, declared latency, throughput.
These are carried in the receipt labeled as Cerebras's own assertion. Hive does not restate them as independent findings, and does not grade them.
Timing captured by an instrumentation layer that sits outside Cerebras's own reporting path, so the same event is timed twice: once by Cerebras's own reporting and once by a separate observer.
Observation covers delivery and instrumentation behavior. It is not a measurement or an estimate of wafer compute time.
Values fixed before the outcome is known, so neither Cerebras nor the observer can revise the record after the fact.
This is the part that keeps working when nobody is around to vouch for it. The commitment structure is checkable without Hive present.
Neither requires the other. Both are additive: Cerebras keeps its current stack, its current model serving path, and its current customer relationships exactly as they are.
Built for streamed inference, where tokens arrive incrementally and the risk is that a fast first token hides a slow or altered tail.
Stipryn™ · before transmission
Stipryn™ fixes the required proof level before transmission, while the party bearing the consequence still controls the request. This happens before the request reaches Cerebras and does not change the request content.
Foretoken · pre commitment
Foretoken commits the request ID and run ID before or concurrently with the first streamed content unit leaving the provider. The commitment is timestamped and fixed before any output exists, so it cannot be adjusted retroactively to match a later result.
Binding during the stream
As streaming proceeds, Hive binds together, without merging: the original request, each streamed delta, the observed timing of each delta, Cerebras's own declared values, and the declared performance budget for the run.
Terminal seal
The seal closes the record immediately after the last token. Because the request and run ID were committed before streaming started, the final artifact cannot be swapped or edited without breaking the pre stream commitment. Any mismatch is visible on inspection.
resultA single sealed record that shows the full life of one streamed response, timestamped at both ends, with nothing added or removed in between.
Built around the wafer assertion itself, not the network path around it.
The proposed structure: a key held by Cerebras signs an assertion about the silicon, for example that a given run executed on a Cerebras Wafer Scale Engine. Hive binds that signed assertion into the receipt alongside the timing data from Surface A or from a similar measurement pass.
This is a path toward an honest Cerebras verified inference claim, one where the cryptographic root of trust for the silicon assertion sits with Cerebras, not with Hive.
A defined test of a provider signed interface: whether a Cerebras held key can sign a silicon assertion, and whether Hive can bind that signed assertion into a receipt without becoming a trust bottleneck.
stated plainlyThis proposal does not assume or claim that Cerebras currently exposes a third party verifiable wafer assertion. We do not know Cerebras's internal attestation capabilities, and we make no claim about them either way.
practical benefitA signature rooted in a Cerebras held key lets a third party check a claim about wafer identity or wafer performance against that key directly, rather than against Hive's word. It keeps Hive out of the silicon trust path. Hive would only ever be the layer that binds and times the assertion, never the party that makes it.
Pre submission proof level binding.
Required proof level.
Proof demand commitment.
Stipryn™ fixes the required proof level before transmission, while the party bearing the consequence still controls the request.
Stipryn does not touch, inspect, or alter the prompt. It is not an agent, and it is not limited to automated traffic; it applies the same way to an ordinary human composed request.
It does not assert that the model's output is correct or safe. It only fixes, ahead of time, what level of proof will be required for a given request, so that level cannot be lowered after the fact to fit whatever result happened to come back.
The party who bears the consequence of the request, meaning the one whose money, service level, or reputation is on the line, keeps full control over what they ask for. Stipryn constrains the proof commitment, not the request itself.
These figures come from a bounded internal sandbox. They measure Hive's own instrumentation overhead and attributable timing gaps within that sandbox, and they characterize delivery and instrumentation boundaries only.
0.1610 ms (p50)
pre commit before first token
0.0046 ms (p50)
per delta observation
0.1781 ms (p50)
final seal after last token
+0.0006 ms
tenant overhead, same sandbox context
notThese are not end to end latency figures, not a measurement or estimate of wafer compute time, not a benchmark of Cerebras or any other provider's silicon, and not production grade performance numbers. Only a provider declared or provider signed value can support a claim about compute time itself. End to end deltas are excluded entirely from this page because they are dominated by network variance that has nothing to do with either party's compute.
The four figures demonstrate two things and only two things: that attributable timing gaps between provider compute and observation are measurable in principle, and that Hive's own instrumentation overhead is small enough to be practically negligible inside a controlled test.
They say nothing about what a customer would see in a live Cerebras deployment. That is exactly what a POC would establish.
Illustrative, not an API specification, and it makes no claim about either party's production interfaces. Fields are grouped deliberately so that provider claims, independent measurements, and cryptographic material never mix in a way that lets one category quietly stand in for another.
receipt {
request_id // fixed at commitment time
run_id // fixed at commitment time
commit_timestamp // pre transmission, from Foretoken
provider_assertion {
silicon_id // provider declared, e.g. wafer identity
model_version
declared_latency_ms
declared_throughput
}
observer_measurement {
pre_commit_ms
per_delta_ms[]
final_seal_ms
tenant_overhead_ms
}
performance_budget {
declared_target_ms
}
terminal_seal {
seal_timestamp
seal_hash
}
signature {
signing_key_holder // Hive, or Cerebras for Surface B
signature_value
}
}provider assertionsobserver measurementscryptographic commitments
| Criterion | Pass condition |
|---|---|
| Pre stream commitment | Request ID and run ID are timestamped before or concurrently with the first streamed content unit leaving the provider. |
| Delta binding | Every streamed delta observed during the run appears in the sealed record, in order, with its own timestamp. |
| Tamper evidence | Any edit to a delta or to the final artifact after sealing produces a detectable mismatch against the pre stream commitment. |
| Terminal seal capture | A seal is generated and attached immediately after the last token is observed, and the seal timestamp is verifiably later than every delta timestamp it covers. |
| Separation of categories | Provider assertions, observer measurements, and cryptographic commitments remain in distinct, labeled fields in the final receipt. |
| Criterion | Pass condition |
|---|---|
| Key custody | The signing key for the silicon assertion is generated and held by Cerebras, not by Hive. |
| Assertion binding | The signed silicon assertion is bound into the same receipt structure as the timing data, without modification to either. |
| Independent checkability | A third party can verify the signature against a Cerebras published key without needing to trust Hive's internal systems. |
| Trust path removal | The chain of trust for the silicon claim runs from Cerebras's key to the verifier, with Hive appearing only as the binder of the record, not as an attester of silicon identity. |
| No overreach | The receipt makes no claim beyond what the signed assertion and the measured timing actually support. |
If Hive proof generation fails, is disabled, or is removed from the path entirely, Cerebras inference continues to run and continues to serve customers without any change to model behavior or delivery.
The proof path is fail open by default: a missing receipt stays visibly missing rather than being backfilled or faked.
Any receipt issued before the failure or removal remains independently verifiable after the fact, because its evidentiary force comes from cryptographic commitments made at the time, not from Hive's continued presence or operation.
Hive does not rank providers and does not publish comparative performance tables.
A signed record that a measurement was taken is not a statement of legal or regulatory compliance.
This is not a claim that Cerebras is, or would become, a Hive customer.
This page describes a proposed proof of concept, written as a private prospect artifact.
No claim about Cerebras's internal hardware, execution environment, or attestation capabilities beyond what Cerebras itself declares or signs.
A proposal to run one bounded proof of concept, on one of the two surfaces above, so that the boundary between wafer scale compute and delivery latency has an answer that does not rely on anyone's word alone.
For a fuller map of how these primitives extend across other Cerebras surfaces beyond the two POC options above, the Proof Architecture Map works through streamed endpoints, silicon and model identity claims, service level commitments and speed based pricing, and renewal, audit, and procurement workflows.
Companion page. Cerebras Proof Architecture Map shows, use case by use case, which of the four filed art proof primitives applies, what it fixes, what evidence it produces, and what it deliberately does not claim. It is a private, noindex prospect page on the same footing as this one.
One surface.
One bounded proof of concept.
Hive builds and runs the proof of concept around the surface Cerebras selects. Neither surface changes the model or the request. The integration scope is limited to the proof fields and signing path Cerebras chooses to expose.
PICK ONE SURFACE. HIVE RUNS THE POC.
source · AMD and Cerebras ultra low latency and high throughput inference announcement, July 23, 2026 https://www.cerebras.ai/press-release/amd-and-cerebras-announce-industry-leading-ultra-low-latency-and-high-throughput-ai-inference · checked August 1, 2026
This is a prospect artifact from Hive Civilization Inc. Cerebras is not a customer. Nothing here implies a partnership, endorsement, deployment, agreement, or customer relationship.
Private technical companion · noindex / nofollow / noarchive · this page is not affiliated with, endorsed by, or produced in cooperation with Cerebras Systems or AMD, and product and company names referred to here belong to their respective owners · the receipt structure shown is illustrative and is not an API specification for either party · sandbox figures characterize Hive instrumentation overhead inside a bounded internal test and are not benchmarks of any provider's silicon · Hive does not observe wafer or GPU internals, and any compute characterization carried in a receipt is a provider declared or provider signed value · Foretoken™ and Stipryn™ are Hive marks; Hive primitives are patent pending · prepared by Steve Rotzin, Founder, Hive Civilization Inc. · Wyoming, USA
Explore Hive Proof Architecture · Cerebras Proof Architecture Map
This receipt adds a separate administration record to a benchmark evidence package and complements the speed work described on this page. It is deployed and open to verify, so the run below is a live check, not a mock.
Benchmark evidence can state who arranged the test and when without changing the performance work already underway. This receipt links a named benchmark administration arrangement to one evaluation attestation. It establishes a test set fingerprint before the subject sees the contents and before the benchmark window begins. The service calculates the independence class from the stated relationship and separation of duties rather than accepting a supplied classification. It keeps the identity of the administrator with the relationship and duty separation as asserted information that is not independently verified.
What it does not do. It has no benchmark score or result and offers no view on whether the test was appropriate or representative, whether a participant got items by another route, or whether the evaluation method was adequate. It cannot attest to administrator competence and is neither an accreditation nor a certification or audit opinion that a standards body, regulator, or insurer currently recognizes.
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.