Parametric Trigger Receipt: settling whether a payout condition actually fired

The problem

A performance obligation is written down. If latency exceeds a threshold over a measured window, something is owed. This shape appears in service level agreements, in performance bonds, and in parametric insurance where the payout is tied to a measured parameter rather than to an assessed loss.

The attraction of the parametric form is that it removes the loss adjuster. Nobody has to argue about how bad the outage was. Either the parameter crossed the line or it did not. The trouble is that removing the adjuster moves the entire argument onto two questions that nobody instrumented: what exactly was the line, and when exactly was it drawn.

Name the parties. The covered party asserts that the threshold was 200 milliseconds and the measurement came in at 240, so the condition fired. The underwriter asserts that the threshold was 250, or that the measurement window did not open until after the incident, or that the measured outputs were never in a state that could produce a determinate answer. A measuring party sits in the middle and asserts that its numbers are right, which is not the point in dispute.

The failure is that the policy document and the measurement configuration live in different systems and are dated by whoever holds them. A threshold in a policy PDF has a date on the cover page. A budget declaration in a monitoring system has a row timestamp in a database the covered party controls. Neither of these is evidence of ordering. A budget declared after its measurement window opened is a budget written with knowledge of what the window contained. A policy digest committed after the budget was declared is a policy tuned to a budget somebody had already seen.

This is not primarily a fraud problem. It is a workflow problem that produces unfalsifiable claims. Teams genuinely do write monitoring configuration after an incident, because the incident is what made them care about the metric. Then months later that configuration is used to argue that a condition fired, and there is no artifact anywhere that distinguishes it from configuration that predated the event.

When the acting and measuring party is autonomous, the workflow problem gets worse. An agent that both measures and evaluates can adjust either half at machine speed and leave a perfectly consistent trail. Every row will agree with every other row. Consistency is not the property in question. Ordering is.

There is a second failure that is quieter. Indeterminacy propagation. An attestation can come back indeterminate, meaning the measurement did not support any outcome. A caller with an incentive can read indeterminate and write satisfied, and downstream nobody sees the attestation, only the trigger. Whatever process consumes the trigger sees a clean binary and acts on it.

The third failure is leakage in the other direction. Policy terms are commercially sensitive. Premiums, limits and payout amounts are things underwriters and covered parties both prefer not to publish. Any instrument that requires the terms to be handed to a third party in order to be checked will not be used, so an instrument that wants to be adopted has to evaluate the condition without ever seeing the money.

What the receipt binds

The schema is at https://thehiveryiq.com/.well-known/schemas/parametric-trigger-v1.json.

The condition is not a threshold expression. It is a required outcome. The threshold lives in the performance budget, the measurement lives in the attestation, and the attestation's own verifier compares them. This receipt asks a narrower question: given that attestation outcome, and given the outcome this condition requires, what is the trigger state.

What is deliberately not in the signed body

The policy terms are absent, and this is enforced rather than assumed. What appears is policy_ref.policy_digest_sha256, a 64 character lowercase hex digest of terms this service never receives. Neither the premium, nor the limit, nor the payout amount, nor the wording is present anywhere.

Absence is checked by NO_POLICY_LEAK. The gate first requires policy_digest_sha256 to be exactly 64 lowercase hexadecimal characters, so an opaque field cannot be quietly repurposed to carry text. It then walks every other string in the signed body and rejects any that matches a currency amount pattern. The pattern covers a currency symbol from the set of dollar, euro, pound and yen signs followed by digits with optional decimal or comma separation, a three letter code from USD, EUR, GBP, CAD, AUD and JPY followed by digits, and digits with thousands grouping followed by one of those codes. Matching is case insensitive. The one exempt path is the policy digest itself.

The commitment machinery is the shared typed receipt construction in src/typed/canon.js. The signed body is canonicalised with keys sorted recursively, arrays kept in order, no whitespace, and every code unit above U+007F escaped as a lowercase \uXXXX sequence so the bytes match Python json.dumps with ensure_ascii=True. The digest is lowercase hex SHA-256 over the UTF-8 bytes of that string. The Ed25519 signature covers the ASCII string

hive-receipt <receipt_id> <payload_sha256> <ts>

The literal prefix hive-receipt is the domain separation label. The same digest function produces attestation_ref.payload_sha256 and budget_ref.payload_sha256, so the trigger commits to the exact bytes of both referenced bodies while carrying neither.

The gates

Verification runs in this order and stops at the first failure.

1. SCHEMA. Validates the envelope against the parametric trigger v1 schema, including the boundary constant. A failure means the artifact is not a well formed instrument of this type.
2. ISSUER_KEY_MATCH. Resolves envelope.key_id in the trusted keyring. A failure means the key does not resolve there, or no trusted keyring resolver was supplied.
3. PAYLOAD_DIGEST. Recomputes the canonical digest over signed_body and compares it to payload_sha256. A failure means the body was altered after signing.
4. RECEIPT_ID. Requires receipt_id to parse into r_<type>_<unix_seconds>_<12 hex> and its type segment to equal signed_body.receipt_type. A failure means the identifier and the body disagree about the instrument type.
5. SIGNATURE. Verifies Ed25519 over the signing string, first against the trusted key for key_id, then against a caller supplied key if one is available. A failure means no available key produced this signature.
6. SIGNER_IDENTITY. Fails when the signature verified only against a caller supplied key, reporting that the bytes are internally consistent while the signer is not trusted here.
7. ATTESTATION_LINK. Requires a performance attestation envelope to be supplied, requires attestation_ref.receipt_id to equal the supplied envelope's identifier, and requires attestation_ref.payload_sha256 to equal the recomputed digest of the supplied attestation body. A failure means the trigger names an attestation that was not produced, or that the produced one has been altered.
8. BUDGET_CONSISTENCY. Requires the supplied attestation to carry its own budget_ref and requires the trigger's budget_ref to match it field for field. A failure means the trigger claims to be governed by a different budget from the one the attestation was measured against.
9. TENANT_MATCH. Requires the trigger tenant_id to equal the attestation tenant_id. A failure means evidence from one tenant is being used to settle another tenant's condition.
10. PRECOMMITMENT_ORDER. Requires a performance budget envelope to be supplied, requires policy_ref.committed_at, the budget's declared_at and the budget's measurement_window.opens_at all to be valid UTC instants, and requires them to satisfy policy committed_at at or before budget declared_at at or before budget measurement_window.opens_at. A failure means the terms or the budget were fixed with knowledge they should not have had.
11. ATTESTATION_INTEGRITY. Runs the full Bonded Performance Attestation verifier over the supplied budget and attestation pair. A failure reports the attestation's own failed gate and reason, which is where the measurement side checks live, including the budget's own declaration ordering and the ratio range constraint on threshold values.
12. INDETERMINATE_PROPAGATION. When the attestation outcome is indeterminate, requires trigger_state to be indeterminate as well. A failure means an unusable measurement was laundered into a usable trigger state.
13. TRIGGER_RECOMPUTE. Derives the expected trigger state from the attestation outcome and condition.requires_outcome and compares it to the stated trigger_state. The failure message names the stated state, the recomputed state, the attestation outcome and the required outcome, so the disagreement is fully diagnosed. A failure means the caller asserted a trigger state the referenced evidence does not produce.
14. NO_POLICY_LEAK. Requires the policy digest to be exactly 64 lowercase hexadecimal characters and rejects any currency amount appearing in any other signed value. A failure names the location and means commercially sensitive terms reached a field that must stay opaque.

The boundary

This receipt attests that a named parametric condition was evaluated against one specific Bonded Performance Attestation, that the policy terms digest was committed at or before the governing budget was declared and the budget was declared at or before its measurement window opened, and that trigger_state was recomputed by this service from the referenced attestation rather than supplied by the caller. It does not create, confirm, price, underwrite, or interpret any insurance policy, and this service never receives the policy terms. It does not establish that any claim is payable, does not effect or authorise any payment, and does not attest that the measured outputs were correct or that any loss occurred. The measuring party is recorded as declared and is not verified here. Whether this trigger state entitles any party to payment is determined solely by the parties' own contract.

That string is a schema constant inside the signed bytes, checked at verification.

The final sentence is the one that makes the instrument usable. It hands the payment decision back to the contract. An underwriter reading a trigger receipt is not being told to pay. The underwriter is being told that a condition evaluated to a particular state against evidence with a fixed ordering, and that the state was derived rather than declared. Everything about entitlement stays where the parties already agreed to put it.

Enumerating the non attestations narrows a dispute quickly. Take the sentence about the measuring party. If the trigger receipt were silent on this, a party who wanted to attack the receipt would spend three months on discovery into whether the measurer was independent, and would then argue that the receipt implied an independence it never checked. Because the receipt says the measuring party is recorded as declared and is not verified here, that whole line of attack is answered in one sentence, and if measurer independence actually matters to the parties they know from day one that they need to establish it some other way.

Same with correctness of measurement. The receipt does not claim the measured outputs were correct. What it claims is that the threshold was pinned before the measurement window opened. Those are different properties and the boundary keeps them apart, so nobody has to litigate a claim the instrument never made.

Adversarial cases

These are the real cases in test/parametric-and-mandate.test.mjs.

Policy committed after budget declaration fails PRECOMMITMENT_ORDER. This is the tuned policy. Terms are written or amended once somebody has seen the budget they will be measured against. The gate compares policy_ref.committed_at to the budget's declared_at and rejects the receipt. Editing the budget body to move declared_at earlier does not work, because ATTESTATION_INTEGRITY re-verifies the budget envelope and a changed body fails its digest.

Budget declared after its measurement window opens fails DECLARED_BEFORE_WINDOW. This is the retrofitted budget, written once the window was already producing data. The check lives in the attestation verifier and surfaces through ATTESTATION_INTEGRITY, and PRECOMMITMENT_ORDER independently enforces the same ordering from the trigger side.

An indeterminate attestation with a satisfied trigger fails INDETERMINATE_PROPAGATION. The forgery upgrades an unusable measurement into a payable condition. The gate reads the outcome from the supplied attestation body, which is digest bound to attestation_ref, so the only way to change it is to break ATTESTATION_LINK first.

A trigger budget reference mismatch fails BUDGET_CONSISTENCY. This is budget shopping. An attestation measured against a lenient budget is presented under a strict one, or the other way round. The gate requires the trigger's budget_ref to match the attestation's own budget_ref field for field, so the pairing cannot be rearranged after measurement.

A mutated attestation body fails ATTESTATION_LINK. Change one number in the supplied attestation and its recomputed digest no longer equals attestation_ref.payload_sha256. The gate fires before any outcome is read.

A caller asserted wrong trigger state fails TRIGGER_RECOMPUTE. The simplest forgery is to write satisfied and hope nobody re-derives it. The stated state is never an input to the derivation. It is only ever a value to compare against.

A currency amount in a schema permitted identifier fails NO_POLICY_LEAK. Schema validation accepts a free text identifier. NO_POLICY_LEAK does not, if that identifier contains something shaped like money.

A ratio threshold outside zero through one fails RATIO_RANGE. Ratio dimensions such as error rate and availability must lie in the inclusive range zero to one. This check lives in the attestation layer and reaches the trigger through ATTESTATION_INTEGRITY.

Two compatibility cases round it out. A legacy r1.0.0 latency budget remains valid unchanged, and a r1.1.0 ratio performance pair evaluates end to end. Adding ratio dimensions did not silently invalidate the receipts already in the field.

Performance

From hive-verifier-api/benchmarks/results-latest.json, measured at 2026-08-09T22:28:01.099Z at commit e167719f7d815809c6f55c5dde4495edf1c5615f over 200 iterations:

Local harness measurement on one machine and one Node version. The run recorded Node v20.20.1 on linux/x64 with two Intel Xeon cores at 2.90 GHz. It is a reproducible measurement of this code, not a production latency guarantee. Mint here is the slowest of the deployed types in this run, which is consistent with a mint path that verifies both a budget and an attestation before it signs.

How to run it

• Host: https://thehiveryiq.com/v1
• Verify route: /verify/parametric-trigger, no credentials required
• Mint route: /mint/parametric/trigger, requires Authorization: Bearer $HIVE_TYPED_MINT_TOKEN

curl -sS -X POST https://thehiveryiq.com/v1/verify/parametric-trigger -H 'content-type: application/json' -d '{"receipt": <a receipt of this type>}'

The open verify route needs no credentials, so it is the fastest honest check available. Mint fails closed with 401 when the token is missing or wrong.

Where it sits in the canon

Family: bpa. Category: typed receipt contract.

It sits directly on top of the Bonded Performance Attestation pair. The performance budget declares thresholds and a measurement window. The performance attestation measures against that budget and produces an outcome. The trigger takes that outcome and one condition and produces a trigger state. Each layer verifies the one below rather than trusting it.

It does not replace the attestation. If you want to know what the system did, read the attestation. This receipt only answers whether a contractual condition matched.

It does not replace the contract. Entitlement to payment is a question for the parties' own agreement, and the boundary says so in the signed bytes.

Status

production_deployed.