Sixteen protocols

Sixteen protocols, each one running.

All sixteen run today, here in your browser and offline from the kit, on fictional ICE records. Open any protocol and press Run. P13 to P16 cover ICE's own teams, starting with sales.

Start at P01 Internal teams: P13

All sixteen at a glance

Every protocol has working code, signed fictional records and tests. Every key in the demonstration is held by Hive. Select any card for the detail and a live run.

P01ICE entitlement evidence profileWorkingThe exact record of one entitlement decision: who asked, for what use, under which rights and policy version, and what the answer was.P02Value-delivery reconciliationWorkingTies a quote and its acceptance to what was delivered and billed, so a retry is counted once.P03Rights Composition ReceiptWorkingWorks out what a derived product may be used for when several licensed sources feed it. Rights never widen on their own.P04Consistent Authorization CutWorkingTies each decision to the exact source versions it read, so a stale answer can be told apart from a fresh one.P05Conserved Usage AllowanceWorkingKeeps a shared usage allowance adding up across teams and systems, so no unit is spent twice.P06Revocation ConvergenceWorkingFollows a rights change to every listed consumer and cache, and shows which ones haven't confirmed it.P07Correction Impact and RelianceWorkingWhen a published figure is corrected, shows which answers, calculations and recipients relied on the old one.P08Source-window ClosureWorkingEach source closes its window with a signed count, so a missing record shows up, including the last one.P09Independent Evidence WitnessWorkingAn append-only log with a witness that cosigns each checkpoint, so a rewritten history or a split view is caught.P10Licensed Answer EnvelopeWorkingPackages an AI answer with the licensed sources and rights checks behind it, so a customer can check it without Hive.P11Private Aggregate Licensing AuditWorkingChecks that seats across all consumers stay within a licensed cap, opening only the records an auditor asks for.P12Evidence RenewalWorkingKeeps old evidence checkable after keys or algorithms retire, resealed with a post-quantum signature.P13Internal Decision RecordWorkingThe record of an internal decision: who approved what, on which exact version, under whose authority.P14Commercial Commitment ChainWorkingFollows a commercial promise from approval to sent, accepted, provisioned and billed, with each step's own evidence.P15Internal Handoff AcceptanceWorkingOne team handing work to another inside ICE. Each obligation is accepted, returned or conditioned on its own.P16Commercial Claim SupportWorkingChecks claims in decks and AI briefs against an approved, dated fact register. An assistant can't approve a claim.

Tested and measured

23 of 23 stress tests pass, alongside the acceptance tests. They include 3,000 random rights graphs, 14,400 concurrent allowance operations and 1,640 Merkle proofs checked against a separate implementation. Timings are from one core of a sandbox machine running the reference code.

Protocol	Operation	Median now	Median on 2026-10-08	Throughput per second
P03	Rights decision, 2 sources, 4 uses	0.014 ms	0.013 ms	50,762 checks
P03	Rights decision, 200 sources, 6 uses	0.738 ms	0.725 ms	1,300 checks
P04	Authorization cut, 2 sources, signed progress	0.286 ms	0.356 ms	3,094 checks
P05	Reserve and consume through the coordinator	0.016 ms	0.051 ms	50,235 checks
P05	Independent replay of a 40,000-entry log	308 ms	1,034 ms	129,643 entries
P06	Revocation check, 3 consumers, signed acks	0.561 ms	0.733 ms	1,628 checks
P07	Correction impact, 3 downstream, 2 recipients	0.422 ms	0.570 ms	2,052 checks
P09	Build a 100,000-record log root	1,500 ms	5,319 ms	66,682 records
P09	Inclusion proof check at 100,000 records (17 hashes)	0.111 ms	0.467 ms	8,584 checks
P09	Consistency proof check 70,001 to 100,000 (18 hashes)	0.151 ms	0.631 ms	6,167 checks
P09	Full witness check, signatures and proofs	0.315 ms	0.498 ms	2,822 checks
P10	Answer envelope check, 3 spans, 2 source receipts	0.428 ms	0.599 ms	2,159 checks
P11	Aggregate audit, 2 openings	0.199 ms	0.407 ms	4,035 checks
P12	Renewal check including ML-DSA-65 verify	2.97 ms	3.86 ms	321 checks
Composite	Parity check, 4 times, 3 symbols, signed both sides	1.00 ms	first timed today	928 checks
Composite	Whole AI answer trace: rights, linkage, count, log, correction	1.44 ms	first timed today	579 checks

Run them yourself from the kit: node tests/protocols-smoke.mjs and node tests/protocols-bench.mjs. Measured 2026-10-14, Node v20.20.1, one core of an Intel Xeon at 2.90 GHz in a shared cloud sandbox. The earlier column is the same test before the speed fixes of 2026-10-14: hashing now runs synchronously instead of through the browser's asynchronous digest call, Merkle trees are built without copying arrays, public keys are imported once and kept, and the post-quantum library moved to a faster release. The 27 product checks built on these protocols are on the next page.

Full detail

Each entry links to the surfaces it serves on the 100-surface map. Draft type names are drafts until a schema and its tests are accepted.

Required profile P01, P08
Composed protocol P02, P06, P07, P12
Candidate primitive P03, P04, P05
Operations and protocol P09
Composed product profile P10
Research option P11
Required internal profile P13
Composed internal sales protocol P14
Required handoff profile and composed protocol P15
Composed product and sales profile P16

P01ICE entitlement evidence profile

WorkingRequired profilePilot laneice.entitlement.event.v1-draft

The exact record of one entitlement decision: who asked, for what use, under which rights and policy version, and what the answer was.

State: Draft schema, strict validator and 14 signed cases in the kit.
What it does: Create a strictly validated market-data event profile and an adapter mapping from the existing demonstration. Keep hive.ice.entitlement_receipt v0.1 byte-for-byte for legacy verification. A proposed 0.2-draft envelope may reference entitlement.reliance.v1 as its design profile; neither is an approved canonical release until its schema and tests are accepted.
Rules: Represent actor and represented subject separately. Carry product, purpose, use class, rights scope, policy version, source coordinate and decision. Allow, deny, partial, review and unknown are source outcomes, not verifier results. Missing rights data is unknown. Do not fill required payment fields with meaningless zeros.
Demonstration: Show an allowed human, allowed agent, denied agent and unknown decision caused by a missing policy version.
Inputs: ICE decision, source epoch/cursor, actor and subject, rights and rule digests, purpose, use class, event/effective/observed times, result and response linkage.
Accepted when: Missing authority/source/version becomes unknown. Allow, deny, partial and review outcomes retain source provenance.
Depends on: None
Reuses: authority.qualification, authority.delegation, delegation.attenuation, delivered.set.containment
Customer surfaces: ICE-01, ICE-02, ICE-03, ICE-04, ICE-05, ICE-06, ICE-07, ICE-10, ICE-11, ICE-16, ICE-26, ICE-27, ICE-31, ICE-33, ICE-43, ICE-46, ICE-48, ICE-51, ICE-60
Internal workflows: INT-08, INT-12, INT-19

P02Value-delivery reconciliation

WorkingComposed protocolPilot lane

Ties a quote and its acceptance to what was delivered and billed, so a retry is counted once.

State: Counting rule ice.data.count.v1-draft runs on the fixture. AT09 passes.
What it does: Link quote, authorized acceptance, permitted scope, logical delivery, acknowledgement, billable use and later credit. Add a data-unit vocabulary with a versioned counting rule. Reuse Counterparty Reconciliation.
Rules: Use stable logical_use_id plus separate delivery_attempt_id. A retry does not become another charge. Acknowledgement is evidence of receipt, not automatically contractual acceptance. Changed quote scope, price or expiry requires new acceptance. Monetary amounts and data units have separate namespaces.
Demonstration: Retry one partly delivered result and count the logical use once. Then change the quote and show that the earlier acceptance is insufficient.
Inputs: Quote ID and expiry; accepted quote digest; unit namespace and scale; logical delivery and attempt IDs; output digest; bill/credit references.
Accepted when: A retry cannot create a second logical unit. Partial results follow the agreed rule. A changed quote requires a new acceptance.
Depends on: P01, P08
Reuses: hivebound.envelope, assembly.receipt, effect.closure, supersession.receipt
Customer surfaces: ICE-03, ICE-07, ICE-08, ICE-11, ICE-13, ICE-27
Internal workflows: INT-06, INT-10, INT-32

P03Rights Composition Receipt

WorkingCandidate primitiveNext lanerights.compose.v1

Works out what a derived product may be used for when several licensed sources feed it. Rights never widen on their own.

State: Bounded rights evaluator over a declared source and transformation graph. AT10 passes; 3,000 random graphs show rights never widen.
What it does: Implement a bounded rights evaluator over an explicit contributing-source and transformation graph. Inputs include source rights roots, authority references, policy versions, requested output use, destination and obligations. Output includes allow, deny or unresolved for each requested use and the applied rule references.
Rules: A known applicable prohibition yields deny. Otherwise allow requires every contributing source to resolve to permission and all duties to be compatible. Missing or conflicting rules yield unresolved. Only owner-approved transformation exceptions may alter ordinary restriction propagation. Viewing, caching, retrieval, embedding, training and redistribution remain separate actions.
Demonstration: Combine an internal-only source with a redistributable source. Internal analysis can pass under approved rules; external redistribution is denied. An unmapped clause produces unresolved. The proof does not discover undeclared inputs or interpret contracts by itself.
Inputs: Source rights roots; authority refs; transformation DAG; allowed destinations/actions; policy version; applicable duties; unresolved clauses.
Accepted when: Derived rights never widen mechanically. Unknown legal clauses remain unresolved. Mixed-source redistribution conflict is reproduced exactly.
Depends on: P01
Reuses: authority.qualification, delivered.set.containment, assembly.receipt, proof.transition
Customer surfaces: ICE-03, ICE-05, ICE-06, ICE-09, ICE-15, ICE-16, ICE-23, ICE-24, ICE-25, ICE-27, ICE-28, ICE-29, ICE-59
Internal workflows: INT-02, INT-08

Benchmark: Rights decision, 2 sources, 4 uses: median 0.013 ms; Rights decision, 200 sources, 6 uses: median 0.723 ms.

P04Consistent Authorization Cut

WorkingCandidate primitiveNext laneauthority.cut.v1

Ties each decision to the exact source versions it read, so a stale answer can be told apart from a fresh one.

State: Dependency and freshness check against signed source progress. AT11 passes; partition, clock-boundary and forged-progress cases read unknown.
What it does: Bind each decision to the exact source versions it read. Record source_id, partition_id, producer_epoch, sequence, dependency vector, decision-read versions, effective_at, observed_at, source checkpoint and clock uncertainty.
Rules: Verify causal dependencies before evaluating freshness. A consistent older cut can still be stale. Source progress must be authenticated for a freshness claim. Effective time and observation time remain distinct. During a partition, unavailable source tails are unknown. Do not infer read sets from timestamps alone.
Demonstration: An identity update depends on policy v5 while the decision reads v4: consistency fails. A coherent older snapshot passes consistency but fails freshness. Without source progress, freshness is unknown.
Inputs: Per-source epoch and sequence; dependency vector; change roots; decision-read versions; effect digest; effective and observed times; clock uncertainty.
Accepted when: Consistent-but-stale differs from fresh. Unobserved source tails or ambiguous boundary times produce unknown, never global valid.
Depends on: P01, P08
Reuses: authority.revocation, sequence.attestation, transparency.checkpoint
Customer surfaces: ICE-01, ICE-02, ICE-04, ICE-10, ICE-22, ICE-26, ICE-31, ICE-32, ICE-33, ICE-36, ICE-37, ICE-38, ICE-39, ICE-40, ICE-41, ICE-42, ICE-43, ICE-44, ICE-45, ICE-46, ICE-48, ICE-49, ICE-50, ICE-52, ICE-56
Internal workflows: INT-25

Benchmark: Authorization cut, 2 sources, signed progress: median 0.353 ms.

P05Conserved Usage Allowance

WorkingCandidate primitiveNext lanequota.conservation.v1

Keeps a shared usage allowance adding up across teams and systems, so no unit is spent twice.

State: Fenced coordinator with atomic reserve, consume and release, plus an independent log replay. AT12 passes; 14,400 random concurrent operations, zero violations.
What it does: Add a typed budget root, non-overlapping allocation tree and fenced authoritative coordinator epoch. Reservation IDs are unique and transitions atomic. At each allocation, assigned child allocations plus local reserved, local consumed and local available units equal the issued allocation.
Rules: Reserve moves available to reserved; consume moves reserved to consumed; release moves reserved to available. Never subtract consumed use merely because a lease expired. Reclaim a child allocation only through an authoritative fenced return or agreed expiry protocol. Separate current allocation accounting from historical use aggregation.
Demonstration: From a 100-unit budget, two simultaneous 60-unit reservations cannot both succeed in enforced mode. Duplicate consume is idempotent. Shadow mode only reports overlap; it never claims prevention. During coordinator outage use agreed preallocated non-overlapping allowances or stop new reservations.
Inputs: Budget root; unit namespace; allocation tree; unique reservation/nullifier; consume/release; source close; coordinator epoch.
Accepted when: Sibling allocations plus consumed and unallocated units reconcile. Concurrent duplicate consumption is refused only by an integrated authoritative coordinator.
Depends on: P02, P08
Reuses: mandate.aggregate, mandate.crossacceptor, proof.transition
Customer surfaces: ICE-08

Benchmark: Reserve and consume through the coordinator: median 0.051 ms; Independent replay of a 40,000-entry log: median 1030.522 ms.

P06Revocation Convergence

WorkingComposed protocolNext lane

Follows a rights change to every listed consumer and cache, and shows which ones haven't confirmed it.

State: Committed consumer roster with signed acknowledgements and cache versions. AT13 passes.
What it does: Track a predeclared roster of entitlement consumers and caches through issued, received and applied rights-change states, then record observed use. Add adapter-specific cache version fields.
Rules: Do not reuse cache.epoch, which describes model KV caches. A missing consumer acknowledgement remains unknown. A closed roster proves only the declared population. Revocation propagation bounds are agreed inputs.
Demonstration: Three declared consumers receive a revocation. Two apply it; the third is silent. The UI shows 2 of 3 acknowledged and an unresolved consumer, not complete revocation.
Inputs: Roster root; source change; propagation bound; per-consumer acknowledgement; cache epoch; subsequent effect observations.
Accepted when: Unresponsive consumers remain unknown. A closed roster is not every possible copy or path.
Depends on: P01, P08
Reuses: authority.revocation, effect.quiescence, supersession.receipt
Customer surfaces: ICE-02, ICE-09, ICE-10, ICE-12, ICE-16, ICE-31, ICE-43, ICE-51, ICE-58
Internal workflows: INT-12, INT-19, INT-25, INT-35

Benchmark: Revocation check, 3 consumers, signed acks: median 0.729 ms.

P07Correction Impact and Reliance

WorkingComposed protocolNext lane

When a published figure is corrected, shows which answers, calculations and recipients relied on the old one.

State: Downstream impact graph with per-revision acknowledgements. AT14 passes.
What it does: Use Decision Evidence Graph to connect original and replacement artifacts to known downstream answers, calculations and recipients. Record notification, acknowledgement and optional recomputation for the exact revision.
Rules: Keep the original unchanged. Old acceptance never transfers to a corrected revision. Missing recipients remain unknown. Do not imply coverage of uninstrumented downstream uses or universal model unlearning.
Demonstration: Correct one pricing input used by two known answers. Show the impacted answers, one acknowledged recipient and one pending acknowledgement.
Inputs: Original and replacement digests; dependency edges; relied-on version; known recipient roster; notify/ack/recompute.
Accepted when: Old evidence remains unchanged. Undeclared downstream uses remain unknown. No recipient acceptance transfers silently to a corrected revision.
Depends on: P08
Reuses: decision.provenance, supersession.receipt, custody.handoff
Customer surfaces: ICE-09, ICE-15, ICE-17, ICE-18, ICE-19, ICE-20, ICE-21, ICE-23, ICE-24, ICE-25, ICE-27, ICE-28, ICE-29, ICE-34, ICE-35, ICE-36, ICE-38, ICE-39, ICE-40, ICE-42, ICE-44, ICE-47, ICE-48, ICE-50, ICE-52, ICE-53, ICE-54, ICE-56, ICE-59
Internal workflows: INT-12, INT-16, INT-17, INT-20, INT-22, INT-24, INT-33

Benchmark: Correction impact, 3 downstream, 2 recipients: median 0.563 ms.

P08Source-window Closure

WorkingRequired profilePilot lane

Each source closes its window with a signed count, so a missing record shows up, including the last one.

State: Signed window checkpoint. AT05 and AT06 pass.
What it does: Close each source_id, partition_id, producer_epoch and eligibility-rule window against independently established start/end coordinates and expected counts. Include received, accepted, rejected, duplicate, late and missing states with a documented counting identity.
Rules: Coverage uses unique eligible source events, not transport attempts. Count acknowledged rejections separately from represented evidence. Expected minus represented equals missing only under the same committed eligibility rule. A closing root over received records alone is insufficient. Without a trustworthy denominator, coverage is unknown.
Demonstration: Use expected source sequences 1001-1007. Omit 1006, then remove 1007. Both cases must retain a coverage failure against the trusted end checkpoint. An absent checkpoint yields unknown, even when all supplied signatures pass.
Inputs: Source ID/partition/epoch; expected range/count; eligibility-rule digest; accepted/rejected/deduped totals; closing root and recipient acknowledgement.
Accepted when: Truncated prefix, missing middle, omitted last window and restarted source epoch cannot become complete. Unknown denominator stays unknown.
Depends on: None
Reuses: sequence.attestation, transparency.checkpoint, ledger.parity
Customer surfaces: ICE-01, ICE-04, ICE-06, ICE-07, ICE-08, ICE-10, ICE-11, ICE-13, ICE-14, ICE-15, ICE-16, ICE-17, ICE-18, ICE-19, ICE-20, ICE-21, ICE-22, ICE-23, ICE-25, ICE-26, ICE-29, ICE-30, ICE-31, ICE-32, ICE-33, ICE-34, ICE-35, ICE-36, ICE-37, ICE-38, ICE-39, ICE-40, ICE-41, ICE-42, ICE-43, ICE-44, ICE-45, ICE-46, ICE-47, ICE-49, ICE-50, ICE-51, ICE-52, ICE-53, ICE-54, ICE-55, ICE-56, ICE-57, ICE-58, ICE-59, ICE-60
Internal workflows: INT-29, INT-40

P09Independent Evidence Witness

WorkingOperations and protocolPilot lane

An append-only log with a witness that cosigns each checkpoint, so a rewritten history or a split view is caught.

State: RFC 9162 Merkle log with inclusion and consistency proofs, witness cosignatures and fork detection. Checked against an independent implementation. In this demonstration the witness key is Hive's, so independence reads unknown, as it should.
What it does: Provide a trust policy and externally retained checkpoint with signer role, key epoch, algorithm, organization and custody evidence. Compare checkpoints where the declared log supports consistency proofs.
Rules: Do not count two Hive-held keys as institutional independence. Fixture keys can simulate distinct roles but must be labelled simulated. A trusted historical checkpoint supports an as-of claim; offline checking does not discover later revocation.
Demonstration: A valid Hive signature passes integrity while independence is unavailable. A separately retained fixture checkpoint exercises the protocol, still labelled a simulated witness.
Inputs: Separate trust policy; signer role and key epoch; inclusion/consistency proofs; external checkpoint retention; witness availability.
Accepted when: A second Hive-controlled key is not an independent witness. Witness outage produces an explicit pending state.
Depends on: P08
Reuses: transparency.checkpoint, Portable Trust
Customer surfaces: ICE-01, ICE-04, ICE-07, ICE-13, ICE-14, ICE-19, ICE-22, ICE-30, ICE-32, ICE-34, ICE-35, ICE-37, ICE-38, ICE-39, ICE-41, ICE-42, ICE-43, ICE-44, ICE-45, ICE-49, ICE-53, ICE-55, ICE-56, ICE-57, ICE-58, ICE-60

Benchmark: Build a 100,000-record log root: median 5188.2 ms; Inclusion proof check at 100,000 records (17 hashes): median 0.461 ms; Consistency proof check 70,001 to 100,000 (18 hashes): median 0.627 ms; Full witness check, signatures and proofs: median 0.497 ms.

P10Licensed Answer Envelope

WorkingComposed product profilePilot lane

Packages an AI answer with the licensed sources and rights checks behind it, so a customer can check it without Hive.

State: Signed answer envelope with span-level source linkage, labelled commentary and the rights result. Verifies offline.
What it does: Export the original constituent receipts, source and answer commitments, claim-span attribution, rights evaluation, quote links, model commentary, corrections, schema versions and verifier/trust manifest.
Rules: Initial release may cover one licensed source. Mixed-source rights depend on P03 and remain unresolved until supported. Attribution does not certify semantic truth. Private source values and commitment openings travel only through an explicitly permitted export.
Demonstration: Export an answer containing a source-backed value and separately labelled model commentary. The offline checker explains the verified linkage and what it cannot check.
Inputs: Full constituent receipts; source/answer commitments; claim spans; rights result; model commentary; checker and trust manifest.
Accepted when: Source linkage does not certify semantic truth. The verifier can replay its declared checks without Hive.
Depends on: P01, P08, P09
Reuses: sigr.gca, assembly.receipt, supersession.receipt, Portable Trust
Customer surfaces: ICE-05, ICE-09, ICE-24, ICE-27, ICE-28, ICE-29, ICE-30
Internal workflows: INT-03

Benchmark: Answer envelope check, 3 spans, 2 source receipts: median 0.595 ms.

P11Private Aggregate Licensing Audit

WorkingResearch optionWatch lane

Checks that seats across all consumers stay within a licensed cap, opening only the records an auditor asks for.

State: Merkle sum-tree commitment with selective openings. A commitment-based reference: not zero-knowledge and not independently reviewed.
What it does: Document an optional research track for private set comparisons or proofs of aggregate licensing predicates. Name the exact circuit, inputs, population, trust assumptions and independently reviewed proof system before implementation.
Rules: No production proof or performance claim is authorized by this specification. Correct math cannot establish omitted consumers or truthful source inputs. A reference implementation is not a reviewed licensing-audit deployment.
Demonstration: Explain the proposed predicate and missing prerequisites. Do not show a fabricated proof-success animation.
Inputs: Auditor-approved predicate; source commitments; issuer signatures; population manifest; circuit/version; openings or proof.
Accepted when: Circuit proves the specified relation only. It cannot establish truthful inputs or undeclared consumers. Independent security review required.
Depends on: P01, P08, P09
Reuses: delivered.set.containment, ledger.parity, SpectralZK reference
Customer surfaces: ICE-11

Benchmark: Aggregate audit, 2 openings: median 0.407 ms.

P12Evidence Renewal

WorkingComposed protocolNext lane

Keeps old evidence checkable after keys or algorithms retire, resealed with a post-quantum signature.

State: Renewal over retained originals and historical trust, sealed with Ed25519 and ML-DSA-65 (FIPS 204). Both must verify.
What it does: Retain original artifacts and historical trust manifests, then attach renewal evidence before a key or algorithm policy expires. Preserve old and new algorithm identifiers and external time evidence.
Rules: A new seal does not repair a false old claim. Require two actual verifiable signatures for a hybrid-signature statement. Keep ML-KEM key encapsulation distinct from ML-DSA signatures. Test archive recovery.
Demonstration: Verify an old artifact against its retained historical trust snapshot, attach a renewal record, and demonstrate that changing the original still fails.
Inputs: Original bytes; historical trust snapshot; renewal manifest; old/new algorithm IDs; external time evidence; retention and recovery policy.
Accepted when: Renewal never repairs false source evidence or silently upgrades an old assurance claim. Both signatures must verify for any hybrid claim.
Depends on: P08, P09
Reuses: retention.policy, transparency.checkpoint, supersession.receipt, Portable Trust
Customer surfaces: ICE-12, ICE-14, ICE-15, ICE-22, ICE-30, ICE-34, ICE-49, ICE-51, ICE-52, ICE-57, ICE-60
Internal workflows: INT-38

Benchmark: Renewal check including ML-DSA-65 verify: median 3.894 ms.

P13Internal Decision Record

WorkingRequired internal profileFirst release laneice.internal.event.v1-draft

The record of an internal decision: who approved what, on which exact version, under whose authority.

State: Draft profile ice.internal.event.v1-draft with a strict validator, bound to native approval IDs and artifact revisions. AT21 and AT22 pass on fictional records.
What it does: Create a common profile for human, agent and system decisions inside ICE. Bind native decision/approval IDs to the actual artifact version, actor and role, delegated authority, policy version, evidence inputs, timestamps and downstream action references. Keep the native application authoritative.
Rules: Use a common evidence envelope with workflow-specific schemas. Do not require a data license or quoted-data unit for an ordinary internal approval. Record source assertions and verified relations separately. Imprimatur is reusable only when its exact four-precondition semantics fit; it is not a generic human-approval stamp.
Demonstration: A price exception is approved in the native workflow. Hive captures that source event and binds it to proposal v3. Editing the proposal to v4 makes the old approval insufficient for changed material terms. Open the sales tour
Inputs: Create a common profile for human, agent and system decisions inside ICE. Bind native decision/approval IDs to the actual artifact version, actor and role, delegated authority, policy version, evidence inputs, timestamps and downstream action references. Keep the native application authoritative.
Accepted when: Native approval, signer/role and artifact revision match; missing authority or version is unknown. Ordinary capture adds no new manual form.
Depends on: P08, P09
Reuses: decision.provenance, authority.qualification, proof.transition, supersession.receipt
Internal workflows: INT-01, INT-02, INT-03, INT-04, INT-05, INT-06, INT-07, INT-08, INT-09, INT-10, INT-11, INT-13, INT-14, INT-15, INT-16, INT-17, INT-18, INT-19, INT-20, INT-21, INT-22, INT-23, INT-24, INT-25, INT-26, INT-27, INT-28, INT-29, INT-30, INT-31, INT-32, INT-33, INT-34, INT-35, INT-36, INT-37, INT-38, INT-39, INT-40

P14Commercial Commitment Chain

WorkingComposed internal sales protocolFirst release lane

Follows a commercial promise from approval to sent, accepted, provisioned and billed, with each step's own evidence.

State: Commitment chain checker over approved, sent, accepted, handed off, provisioned and billed records. AT22, AT24 and AT25 pass. See the two-minute sales tour.
What it does: Connect the approved capability and commercial terms to the exact version sent, the customer acceptance evidence, implementation obligations, provisioning and invoice references. Represent each commitment as a stable item with scope, owner, conditions, revision and fulfillment evidence.
Rules: Keep internal approval, outbound delivery, customer acknowledgement, contractual acceptance and fulfillment distinct. Require authentic source evidence for each. A click, presentation receipt or matching digest alone does not establish legal agreement. Use P02 only when its data-value quote model applies.
Demonstration: Sales promises internal-use access. A draft changes the promise to external redistribution. A version/policy mismatch appears for review; only ICE's native approved process can authorize the new promise. A later billing question is traced back to the exact accepted terms. Open the sales tour
Inputs: Connect the approved capability and commercial terms to the exact version sent, the customer acceptance evidence, implementation obligations, provisioning and invoice references. Represent each commitment as a stable item with scope, owner, conditions, revision and fulfillment evidence.
Accepted when: One view explains the approved, sent, accepted, provisioned and billed versions. Every gap has a named missing source or mismatch.
Depends on: P13, P15
Reuses: hivebound.envelope, authority.qualification, proof.transition, intent.affirmation, supersession.receipt
Internal workflows: INT-01, INT-06, INT-07, INT-08, INT-09, INT-10, INT-11, INT-12, INT-15, INT-19, INT-20, INT-27, INT-32

P15Internal Handoff Acceptance

WorkingRequired handoff profile and composed protocolFirst release laneice.team.handoff.v1-draft

One team handing work to another inside ICE. Each obligation is accepted, returned or conditioned on its own.

State: Draft team profile ice.team.handoff.v1-draft inside one organization, with per-obligation accept, reject and conditional accept. AT26 passes.
What it does: Bind the sending and receiving ICE teams, accountable roles, work-package revision, obligations, due conditions and explicit accept/reject/conditional-accept response. Link later fulfillment or escalation as separate events.
Rules: The inspected custody.handoff contract assumes two organizations. Do not impersonate two legal organizations for an internal team transfer. Use a reviewed team profile. An assigned task is not an accepted handoff; accepted responsibility is not completed work. Preserve exceptions and reassignment history.
Demonstration: Sales sends an accepted deal to implementation. Implementation accepts two obligations and flags one unsupported right. The outstanding obligation stays visible with an owner. Open the sales tour
Inputs: Bind the sending and receiving ICE teams, accountable roles, work-package revision, obligations, due conditions and explicit accept/reject/conditional-accept response. Link later fulfillment or escalation as separate events.
Accepted when: Same-organization handoffs validate under the team profile; no fictitious organization boundary is introduced. Completion needs an independent effect reference.
Depends on: P08, P09
Reuses: proof.transition, effect.closure, sequence.attestation
Internal workflows: INT-11, INT-12, INT-14, INT-15, INT-20, INT-21, INT-22, INT-24, INT-26, INT-27, INT-28, INT-29, INT-30, INT-32, INT-35, INT-37, INT-38, INT-39, INT-40

P16Commercial Claim Support

WorkingComposed product and sales profileFirst release lane

Checks claims in decks and AI briefs against an approved, dated fact register. An assistant can't approve a claim.

State: Claim support check against a versioned fact register entry. AT23 passes. The register itself is fictional.
What it does: Link material claims in sales decks, demos, proposals and AI briefs to a versioned owner-approved fact or evidence register. Each claim records scope, conditions, validity period, supporting artifact and human approval where required.
Rules: A source match does not certify semantic truth. Flag missing, expired or materially mismatched support. A generative assistant may explain links but cannot invent approved capabilities. Changes in source evidence mark known dependent sales assets for review. P03 is additionally required for mixed-source data-use rights.
Demonstration: A sales deck claims a capability is available. The source register supports only a bounded demonstration. The review shows the precise unsupported wording and the approved scope, with the corrected version retained. Open the sales tour
Inputs: Link material claims in sales decks, demos, proposals and AI briefs to a versioned owner-approved fact or evidence register. Each claim records scope, conditions, validity period, supporting artifact and human approval where required.
Accepted when: Unsupported or expired claims remain unresolved; approved source versions are visible. No claim becomes approved merely because AI drafted it.
Depends on: P13, P07
Reuses: assembly.receipt, decision.provenance, disclosure.presentation, supersession.receipt
Internal workflows: INT-02, INT-03, INT-04, INT-05, INT-08, INT-17, INT-18, INT-21, INT-23, INT-33

Generated on 2026-10-07 from the build specification by ice/data/build_protocols.py. Public projection. Candidate mappings only. Owners are likely owners to confirm. Nothing here is connected to ICE.