New modeled surface
Why was the request allowed?
Follow one made-up request from Northstar through sign-in, the agent's permission, the ICE license and the allowed use. ICE still makes every call.
Explore entitlement evidence →Four cases. Pick one. Sound on.
One delivery. Two memories of it. One record both sides can check.
All four customers are fictional. Every case uses the same record.
1 of 6
Every evening, ICE delivers data customers run money on.
Two questions, one request
One request has two evidence questions.
Why was it allowed?What happened after ICE delivered it?
Demoed
What was actually delivered?
Follow the same request after ICE sends the data: which version went out, any retries, and whether the customer got exactly what was sent.
Run the delivery demo →Try it yourself
Change the record. Watch it stop matching.
This is the record Northstar kept for the example delivery. The fingerprint on the right was taken when it was sealed. Change anything and your browser recomputes it on the spot. Nothing is sent anywhere.
DELIVERY RECORDExample · not ICE data
- Package
- Northstar EOD 2026.09.16-A
- Product
- End-of-day fixed-income pricing and reference data
- Entitlement
- Authorized
- Transport attempts
- 2 (first acknowledgement lost)
- Same content both attempts
- Yes
Sealed fingerprint
...Fingerprint now
...MATCHESThis is the record as it was sealed.
SHA-256 over the record fields, computed by your browser with the Web Crypto API. The signature check on the full record is in the technical verifier.
What it answers for ICE
The questions that cost time today, answered from one record.
Customer support
"Did we ever get it?"
The customer opens the record they already hold. No log pull, no back and forth.
Usage and metering
"Was that one delivery or two?"
Retries stay tied to the delivery they belong to, so a resend can be told apart from new usage.
Licensing review
"What did they receive, under which entitlement?"
Each delivery carries the entitlement decision that allowed it, in order, with a timestamp.
Customer trust
"Can we check it ourselves?"
The customer keeps their own copy and checks it offline. Instead of "trust our logs," it becomes "check it yourself."
Who does what
ICE runs the delivery. Hive keeps the record beside it. People decide.
ICERuns the workflow
Receives the request, applies entitlement, sends the data, retries, supports the customer and decides billing. Nothing about that changes.
HIVEKeeps the record
Reads agreed events after ICE has served them, fingerprints each one, chains them in order and signs the chain. Never in the delivery path.
PEOPLEDecide what it means
An approved ICE or customer reviewer reads the record and decides. Hive shows what happened. It never rules on it.
- Hive never delivers, blocks or slows data
- Hive never holds the data itself, only fingerprints
- Hive never decides entitlement, billing or fault
- If Hive is down, ICE keeps delivering
- Restricted fields stay out of the record
- Counts on the record are not an agreed billing quantity
Next step
Pick one workflow and we'll sketch it together.
You choose the workflow and the people who should see it. We map which events would land on the record and what each side would hold. Hive stays outside the delivery path the whole time.
What a sketch gives you
- The events that would be recorded
- What ICE and the customer would each hold
- Where the two sides could differ
- What production would need
For entitlements, the first focus ICE named, there is also a 90-day test* on the table.
* Entitlements only. Nothing has been agreed.