Mandate Conformance Receipt: settling whether one agent transaction fit the authority it was given

The problem

An agent holds a delegated mandate to spend on a card. The mandate is bounded: a maximum amount, one currency, a validity window, a scope. The agent buys something. Weeks later someone objects.

Who says the purchase was inside the mandate? Today the platform that ran the agent says so. It looks at its own mandate record, looks at its own transaction record, and reports that the two are compatible. The account holder has no independent copy of either. The issuer has a transaction but no mandate. The merchant has a transaction and knows nothing about any mandate at all. Four parties, four partial views, and the only party with both halves is the one being questioned.

Consider what each would assert without evidence. The platform asserts the mandate allowed 200 units, the purchase was 180, therefore the purchase was fine. The account holder asserts the mandate was for 100, or that it had already expired, or that it never covered this category of purchase. The issuer asserts a card was used and authorisation succeeded, which says nothing about any delegation. The merchant asserts goods were shipped.

None of these can be checked against the others. The mandate record lives in the platform's database and can be edited. That is the specific failure. A mandate written after the fact is indistinguishable from a mandate written before the fact, if both are rows in the same table with the same shape. The account holder cannot prove the mandate was widened retroactively, and the platform cannot prove it was not. When the acting party was a human employee this mattered less, because a human can be asked what they understood their authority to be. An agent has no recollection to offer. It executed the row it was handed.

The second failure is currency. A mandate is written for 100 in one currency, the agent buys for 100 in another, and a reporting layer compares the two numbers because they look the same. Minor unit handling makes this worse. A ceiling expressed as a decimal amount has to be converted to integer minor units before comparison, and the number of minor places is not two for every currency. Get that conversion wrong by a factor of a hundred and a wildly out of bounds transaction reports as compliant.

The third failure is scope. The delegation grants specific capabilities. Nobody checks that the delegation actually granted the capability the transaction used, because scope lives in a different part of the schema from amount and gets checked by a different team, if at all.

This receipt puts all three comparisons in one signed artifact, done by a party that recomputes rather than reports. It requires the delegation to be supplied, verifies the delegation's own signature, requires the delegation's signing timestamp to precede the transaction, and derives the conformance rows itself. What the account holder gets is an arithmetic result anyone can rerun from the same two documents.

What the receipt binds

The signed body carries these fields. The schema is at https://thehiveryiq.com/.well-known/schemas/mandate-conformance-v1.json.

What is deliberately not in the signed body

No cardholder credential appears anywhere. There is no primary account number, no expiry, no verification value. The transaction is identified by transaction_fingerprint_sha256, a 64 character lowercase hex digest, and by a merchant identifier. This is not a convention. A gate actively hunts for card numbers and refuses to verify a receipt containing one.

The delegation itself is not embedded. The receipt carries mandate_ref.payload_sha256, which is the canonical digest of the delegation's signed body, computed with the shared construction in src/typed/canon.js: keys sorted recursively, arrays left in order, no whitespace, every code unit above U+007F escaped as a lowercase \uXXXX sequence, then lowercase hex SHA-256 over the UTF-8 bytes. The Ed25519 signature covers the ASCII string

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

The prefix hive-receipt is the domain separation label, so a signature over a receipt cannot be replayed over any message that does not start with those exact bytes.

The optional window extension goes further and keeps two numbers confidential. The cumulative ceiling and the running total both appear only as keyed commitments, implemented in src/typed/window-aggregation.js. The construction is HMAC-SHA256 keyed by a per window salt, over a domain separated tuple whose parts are joined with a NUL character, \u0000. Three labels are used, and they never overlap:

• hive.window.limit.v1 over [max_total_minor, max_count, currency] produces limit_commitment. This commits to the ceiling and never to the running total.
• hive.window.notional.v1 over [total_minor, currency] produces aggregated_notional_commitment. This commits to the running total and never to the ceiling.
• hive.window.aggkey.v1 over [actor_id, authority_id] produces aggregation_key, which groups actions into one accumulation without naming either party.

salt_commitment is a plain SHA-256 over the salt bytes, so a salt holder can confirm that one salt produced both commitments without revealing the salt.

Severity is disclosed as a class rather than a value. magnitude_class comes from a fixed ladder over the excess proportion: at_or_under, then over_by_up_to_1_pct at or below 0.01, over_by_1_to_10_pct at or below 0.10, over_by_10_to_50_pct at or below 0.50, and over_by_more_than_50_pct beyond that. The buckets are not configurable.

The gates

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

1. SCHEMA. Validates the envelope against the mandate conformance v1 schema. A failure means this 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 resolver was supplied.
3. PAYLOAD_DIGEST, RECEIPT_ID, SIGNATURE and SIGNER_IDENTITY. The shared envelope layer. The canonical digest of signed_body is recomputed against payload_sha256, receipt_id has to parse and declare the same type as the body, the Ed25519 signature has to verify against the trusted key or a caller supplied key, and SIGNER_IDENTITY fails in the second case.
4. NO_PAN. Walks every string in the signed body, strips spaces and hyphens, and rejects any 13 to 19 digit run that passes the Luhn check. A failure names the exact path and means a payment account number reached a field that must never hold one.
5. MANDATE_LINK. Requires a delegation envelope to be supplied and requires mandate_ref.receipt_id, mandate_ref.payload_sha256 and mandate_ref.delegation_id to match the supplied delegation's identifier, recomputed body digest and declared delegation identifier. A failure means the receipt names a delegation that was not produced, or a different one.
6. MANDATE_INTEGRITY. Runs the full delegation link verifier over the supplied delegation. A failure reports the delegation's own failed gate and reason, so a bad mandate is diagnosed as a bad mandate rather than as a bad conformance.
7. MANDATE_PRECEDES_TRANSACTION. Requires transaction.authorized_at to be a valid UTC instant and requires the delegation's envelope ts to be at or before it. A failure means the authority was signed after the action it supposedly authorised.
8. VALIDITY_WINDOW. Requires transaction.authorized_at to fall inside the delegation's validity.not_before and validity.not_after. A failure means the mandate was not live when the transaction happened.
9. AMOUNT_WITHIN. Requires the delegation to state constraints.max_amount, then runs the conformance evaluation to confirm the ceiling is representable in the delegation currency's minor units. A failure means the mandate is unbounded, so no conformance finding is possible, or the ceiling cannot be expressed exactly as an integer minor amount.
10. CURRENCY_MATCH. Requires the delegation to state constraints.currency as a string. A failure means the transaction currency has nothing to be compared against.
11. SCOPE_MATCH. Requires the delegation scope to be an array. A failure means the granted capabilities are not in a comparable shape.
12. CONFORMANCE_RECOMPUTE. Rebuilds the three comparison rows from the delegation and the transaction and requires the receipt's conformance array to match them field for field, including row count. The amount row compares transaction.amount_minor to the ceiling converted to minor units using a fixed table where a listed zero decimal currency scales by one, a listed three decimal currency scales by one thousand, and everything else scales by one hundred. The scope row requires payment.initiate to be present in the delegation scope. A failure names the row index and the field that disagrees.
13. OUTCOME_RECOMPUTE. Derives the outcome from the recomputed rows and compares it to the stated outcome. A failure means the caller asserted a finding the rows do not support.
14. INITIATOR_COHERENCE. Requires an agent initiator to carry human_present false and a nonempty agent_did, and requires a human initiator to carry no agent_did. A failure means the initiator record contradicts itself.
15. WINDOW_BOUNDARY_PRESENT. Always runs. When no evaluation_window is present this is the only window gate, and the receipt is a per action receipt. When the extension is present, the remaining window gates run in order: WINDOW_SCHEMA, WINDOW_BOUNDS_ORDERED against the transaction instant, WINDOW_LINK, WINDOW_PREDECESSOR_INTEGRITY over the prior window envelope, WINDOW_CONTINUITY, SALT_BINDING, then COMMITMENT_RECOMPUTE, WINDOW_VERDICT_RECOMPUTE, BREACH_CLASS_COHERENCE, COUNT_COHERENCE and NO_POSITION_LEAK. COMMITMENT_RECOMPUTE fails when the cumulative constraint or the accumulated action list was not supplied to the verifier, and fails when any accumulated action is denominated in a currency other than the window currency, because no conversion is performed.

The boundary

This receipt attests that the named transaction's amount, currency, timing and scope were compared against the constraints of one specific delegated authority receipt that was signed before the transaction was authorised, and that the outcome was recomputed by this service from that comparison rather than supplied by the caller. It does not attest that the cardholder granted the delegation, that the declared agent identity is genuine, that the transaction was authorised or settled by any network, that goods or services were delivered, or that the displayed terms digest corresponds to anything a person actually read. It is not a payment authorisation and carries no cardholder credential. No card network, issuer, or regulator currently recognises this receipt as authentication data, as compelling evidence, or as a liability shift, and it does not create one. It does not deny, resolve, adjudicate or affect any dispute, and it does not limit any right a consumer holds under Regulation E, Regulation Z, or any equivalent rule. This receipt evaluates one transaction against a per transaction constraint and does not evaluate cumulative spend, transaction velocity, or any aggregate limit across multiple transactions under the same mandate, so a series of individually conforming transactions may still exceed a spending intent this receipt cannot see. It evaluates the delegated authority receipt as supplied and inherits that receipt's revocation limitation, so it does not attest that the mandate was still unrevoked at the moment the transaction was authorised.

This is a schema constant inside the signed bytes and it is checked at verification.

Read the sentence about card networks again, because it is the one people expect to be softened. The receipt says in its own signed body that no network, issuer or regulator recognises it as a liability shift. Stating that is what lets the receipt be used at all. A compliance officer evaluating whether to accept these artifacts asks one question first: what does accepting this commit me to? If the answer has to be extracted from a sales conversation, the answer is no. If it is written into the artifact and checked by the verifier, the officer can accept it as evidence about an arithmetic comparison.

The revocation sentence is the same move. An honest reader would eventually ask whether the mandate was still live at the moment of the transaction. The receipt answers before being asked: it checked the validity window as written on the delegation, and it did not check for revocation. Nobody has to discover that limitation during a deposition.

The velocity sentence points at a real gap and at its own fix. A hundred conforming transactions can still blow through a spending intent. That is what the Cumulative Mandate Receipt exists to catch, and the boundary tells you to go get one.

Adversarial cases

These come from test/parametric-and-mandate.test.mjs.

A Luhn valid card number in merchant_id fails NO_PAN. A forger who wants to smuggle a card credential through a receipt cannot hide it in a free text identifier field, because the gate walks every string, strips spaces and hyphens, and Luhn checks every 13 to 19 digit run it finds. Schema validation would have accepted the field. The gate does not.

An outside transaction forged as within fails CONFORMANCE_RECOMPUTE. The forger sets each conformance row's result to pass and the outcome to within_mandate. The service rebuilds the rows from the delegation and the transaction and compares field for field. The row values are never read from the receipt as input to the decision.

A delegation signed after authorization fails MANDATE_PRECEDES_TRANSACTION. This is the retroactive mandate. Someone spends first and writes the authority afterward. The gate compares the delegation envelope ts against transaction.authorized_at. Backdating the delegation body does not help, because the ts is inside the signing string and changing it invalidates the signature.

An agent marked human present fails INITIATOR_COHERENCE. The self serving edit here is to claim a human was in the loop for an action an agent took alone, which is the shape of a defence in a dispute. A transaction outside the delegation validity window fails VALIDITY_WINDOW, on time bounds read from the delegation rather than from the conformance receipt.

Mints and verifies outside_mandate without treating the record as invalid. This is the case that matters most for honesty. A truthful record of an out of bounds action verifies. The instrument is not a compliance stamp that only exists when the answer is favourable.

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, recorded on Node v20.20.1, linux/x64, two Intel Xeon cores at 2.90 GHz. It is a reproducible measurement of this code, not a production latency guarantee.

How to run it

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

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

Mint fails closed with 401 when the token is missing or wrong. The signer has no unsigned path and no simulated path.

Where it sits in the canon

Family: authority. Category: typed receipt contract.

Downward it composes with authority.delegation, which it requires, verifies and refuses to substitute for. Upward it composes into mandate.aggregate, which takes a set of conformance receipts under one delegation and answers the cumulative question this one cannot. It does not replace payment authorisation, since nothing here talks to a network, and it does not replace whatever revocation evidence you separately need.

Status

production_deployed.