You already promised to pay
when the agent gets it wrong.
There is no signed record of an agent getting it wrong.

Tie the agent that acted to the registration it entered under

The receipt takes two things. One admission credential, and one receipt of something the agent did. It checks that both name the same subject, by deriving a commitment from each under a single salt the credential itself already committed to. The gate is SUBJECT_COMMITMENTS_IDENTICAL and it wants the two commitments byte identical. Then TEMPORAL_RELATION checks that the conduct happened at or after the admission and inside a maximum separation that was signed in advance, so a credential cannot be stretched over conduct it was never meant to cover.

Neither identifier appears in the signed body. The subject is carried as a commitment, so the receipt travels to a counterparty or a regulator without naming the agent, the operator or the Card Member. What it gives an agent operator is simple. If a claim turns on which agent was acting, both sides can recompute the same answer from the same two artifacts, and neither side has to open its registration system to the other.

What it does not prove, in plain words. It does not say your credential was validly issued or that you were entitled to admit the agent. That is your act and this receipt does not reach into it. It does not say the conduct happened or that the conduct was allowed. It only ties two artifacts to one subject and puts them in order. The boundary, verbatim from the schema. This receipt attests only that a supplied admission credential and one supplied conduct receipt yield byte identical subject commitments under one disclosed binding salt that the admission credential already commits to, and that the extracted conduct instant is at or after the stated admission instant and within the signed maximum separation. It does not attest that the admission credential is validly issued, that any admitting party is entitled to admit, that either identifier is true, that the subject is a person or entity of any asserted kind, that the conduct occurred, or that the conduct is authorized. It does not decide authenticity beyond the checked signatures and stated verification class, completeness of records, actual knowledge, intent, fault, fraud, contractual effect, legal effect, regulatory effect, eligibility, title, responsibility, liability, or any dispute. It does not authorize admission, access, conduct, a transaction, credential presentation, disclosure, or reliance by any party. It does not establish that either source artifact is complete, exclusive, current, unrevoked, unaltered before receipt, or truthful. It cannot decide whether an absent conduct receipt exists, whether another admission credential exists, whether the admitting party relied on the credential, whether the conduct service observed all conduct, or whether any party knew of the other artifact.

The summary a person confirmed and the summary you received are the same bytes, in that order

Two opaque records go in, one for what was shown and one for what was sent. The service digests each one separately and compares them at ARTIFACT_EQUALITY_RECOMPUTE, so equality is a real comparison rather than a restatement of a field the caller filled in. Then AFFIRMATION_ORDERING_RECOMPUTE requires the affirmation instant to fall strictly between the presentation instant and the transmission instant. Strictly. An affirmation stamped at the same moment as the presentation fails, and so does one stamped at transmission. The result is an ordering_class of affirmation_bracketed or affirmation_outside_bracket, and the mint path refuses to sign the second one at all.

All three instants are placed against an external time reference the operator declares, with a drift bound. TIME_REFERENCE_INTEGRITY recomputes the digest of that reference and DRIFT_BOUND_SATISFIED fails the receipt when the observed drift runs past the bound the operator itself declared. The channel is recorded too, as interactive_display, voice_playback, messaging_thread or embedded_webview, so a spoken readback and an on screen confirmation are distinguishable a year later.

Here is the honest part, and it is the part worth reading out loud. This receipt says nothing about a person. It fixes bytes and order. What it removes is the gap between the summary a human saw and the summary that arrived, which is the one thing nobody outside the agent operator can currently check.

What it does not prove, in plain words. It does not say a human was there, that anyone read the summary, or that anyone understood it. It does not say the summary was a fair summary of what the person asked for. The channel and the time reference are recorded as declared and are not checked against the world. The boundary, verbatim from the schema. This receipt attests only that the digest of the artifact presented for affirmation equals the digest of the artifact transmitted as the authenticated intent, and that the affirmation instant falls strictly between the presentation instant and the transmission instant, with all three instants placed against a declared external time reference and drift bound. It does not attest that a human was present, that anyone read, understood, or agreed to anything, that the presented summary is a faithful summary of what any person said, that the affirmation was freely given, or that the presented artifact was rendered legibly. The channel and the time reference are recorded as declared and are not verified here.

Classify whether an intent was checkable at the moment it was fixed, not after the loss

The operator declares the kinds of predicate its committed intent contained. Not the text. Kinds, carried as keyed pseudonyms. The service classifies each kind against a published ruleset and recomputes a verifiability_class of machine_checkable, partially_checkable, subjective or unclassifiable. The class is never accepted from the caller. VERIFIABILITY_CLASS_RECOMPUTE derives it, and mint refuses to sign a body that arrives with the class already filled in.

The gate that makes this worth anything is RULESET_PRECEDENCE. The digest of the classification ruleset has to have been committed at or before the instant the intent was fixed. If the ruleset came later, the receipt gets a precedence_class of ruleset_follows_intent and fails closed, and mint will not sign it. So nobody writes the rule that decides checkability after they know what the purchase turned out to be. That cuts both ways on purpose. It stops an operator claiming a loose intent was checkable, and it stops anyone tightening the ruleset once a claim is on the table.

The service never sees the intent. NO_INTENT_CONTENT_LEAK is a gate, the confidential intent object has to be a digest rather than any text, and the schema will not accept a body carrying words a human said. You keep the intent. The receipt carries the shape of it.

What it does not prove, in plain words. It does not say the intent was reasonable or that the Card Member understood it. It does not say the declared predicate kinds are complete or honestly declared, and it does not say these are the predicates a court or a regulator would think mattered. It decides no claim, either way, and it entitles nobody to rely on the class. The boundary, verbatim from the schema. This receipt attests only that a named observer recomputed a verifiability class from the declared predicate kinds of one committed intent, against a classification ruleset whose digest was committed at or before the intent was fixed. It does not attest that the intent was reasonable, that the Card Member understood it, that the declared predicate kinds are complete or honestly declared, that the predicates are the ones a court or regulator would consider material, that any claim is payable or deniable, or that any party is entitled to rely on the class. This service does not read the intent text and never receives it.

Four classes, and the fourth one is the one that keeps you honest

machine_checkable means every declared kind can be evaluated by a machine. Amount, merchant, window, quantity. partially_checkable means some can and some cannot, which is what most real instructions look like. subjective means none can, which is the case your terms already name. Then there is unclassifiable, which fires when the precommitted ruleset never named one of the declared kinds. It is not a hedge. It is the receipt refusing to guess about a predicate nobody had classified in advance, and it is the state a careful reader will look for first.

Run the case below and watch it come back unclassifiable with valid true. A receipt that returns a clean answer for every input is a receipt that is not checking anything. This one has a state for “the rule you committed to does not cover this,” and it uses it.

Where this lands in practice. A denial on subjectivity is currently a judgement, made after the fact, by the payer. With this object the class was fixed when the intent was fixed, against a ruleset published before it, and the operator and the Card Member can recompute the same class from the same commitments. The denial does not become right or wrong. It becomes checkable.

What it does not prove, in plain words. A class is not a claim outcome. Nothing here says a claim is payable or deniable, and nothing here reads the intent text. It does not receive it. The full boundary is printed on the card above and in the canon entry.

The signer is not a party to the transaction, and the schema will not let it be

The receipt carries a field called observer_role, and the schema fixes it to the single value non_party_observer. The verifier runs a gate named OBSERVER_ROLE_DECLARED that fails the receipt if the value is anything else. So the signer is not the issuer, not the acquirer, not the merchant, not the network and not the agent operator. That constraint is the whole point. A party that stands to gain from a finding cannot sign that finding and expect it to settle an argument, because the other side reads the signature and reads the incentive at the same time. Amex signing that Amex was right is a statement. A party with nothing at stake signing a recomputation is something an agent operator or a regulator can act on.

The interesting gate is MANDATE_LIVENESS_RECOMPUTE. The verifier does not accept the liveness_class in the receipt. It rederives it from the mandate reference and the revocation snapshot the observer committed to, and it fails if the two disagree. The liveness evaluation also has to fall within 60 seconds of the decision instant, checked by DECISION_INSTANT_ORDERED. That is what turns "the mandate was live" from a claim into an arithmetic result.

The boundary, verbatim from the schema. This receipt attests only that a named observer recomputed the stated authorization decision from the supplied confidential evidence at the stated instant. It does not attest that the underlying goods or services were delivered, that the cardholder intended the purchase, that the merchant is legitimate, that funds settled, that the issuer honored the decision, or that any party outside the named observer agrees with the finding.

Every constraint has to be timestamped before the loss, or the receipt refuses to name anyone

The precedence rule is the part to read twice. A precommitment only counts if it was committed strictly before the loss instant. The verifier computes a precedence_class of either all_precommitments_precede_loss or some_precommitments_follow_loss, and it recomputes that from the timestamps rather than trusting the field. Nobody gets to write a rule after the loss and then point at it. That is the single most common way a post incident allocation goes wrong, and this closes it.

The attribution_class comes out as single_party, shared, no_violation_found or indeterminate. Here is the honest part. In the hindsight case below, the precommitments post date the loss, so precedence fails and the receipt returns indeterminate. It names nobody. That is not the tool falling short. A tool that refuses to guess is the only kind you can put in front of a regulator, because the first thing an opposing party does is look for the case where it guessed.

The recovery point. American Express has published a commitment to pay when a registered agent errs, on the Agentic Commerce Experiences page, and has not published a mechanism for recovering that payment from the agent developer. A recovery clause has to be written against something. Fault attribution is the object it gets written against. The receipt says which role's precommitment the observations broke, and the contract says what follows from that.

The boundary, verbatim from the schema. This receipt attests only that a named observer recomputed which precommitted constraints the supplied observations violated, and which parties had made those precommitments before the loss instant. It does not attest that the loss occurred, that the observations are complete, that any party acted with intent, that any legal duty was breached, or that any amount is owed.

Place the action against the cancellation and a propagation bound committed in advance

The receipt names an action, a revocation and a propagation bound, and returns a classification of before_revocation, within_propagation_bound, after_propagation_bound or indeterminate. CLASSIFICATION_RECOMPUTE derives that from the instants rather than trusting the field. PRECOMMITMENT_ORDER requires the propagation policy to have been issued strictly before the revocation, using the wide end of each declared clock error, so a bound written to fit a known incident does not survive.

CLOCK_CONSERVATISM is the gate to notice. When the declared clock error on the two instants overlaps enough that the order genuinely cannot be resolved, the receipt has to say indeterminate, and a definite classification fails. Most systems round the ambiguity in favour of whoever is holding the log. This one refuses to.

Notification is recorded separately and honestly, as direct_notification_evidence, publication_evidence or none, checked by NOTIFICATION_EVIDENCE_CANDOUR. That keeps “we published it” and “we told them” from collapsing into the same claim.

What it does not prove, in plain words. A verdict of within_propagation_bound does not excuse the action and it does not allocate fault. It does not say the revocation was authorized, delivered, valid or effective, and it does not say the action was authorized or wrongful. It puts two moments in order against a bound somebody committed to first. The boundary, verbatim from the schema. This receipt attests only that a named action, a named revocation, and a precommitted propagation bound satisfy the stated deterministic temporal classification procedure. It does not establish that the revocation is authorized, delivered, valid, enforceable, or effective as a matter of contract or law. It does not establish that the action is authorized, unauthorized, excused, ratified, wrongful, binding, or ineffective. A class of within_propagation_bound does not excuse the action and does not allocate risk, fault, responsibility, liability, loss, or remedy. Notification evidence records only the stated evidence class and does not establish that an actor receives, reads, understands, or has actual knowledge of revocation. This receipt does not decide any contractual, statutory, regulatory, evidentiary, or legal consequence, and it does not authorize any action, payment, sanction, denial, or remedy.

A settlement position, looked up in a table that was committed before the loss

Two parties agree an allocation table in advance and commit its digest. Later, one verified fault.attribution receipt gets handed in. The service recomputes an attribution_outcome_key from that receipt, looks the key up in the committed table, and signs the resulting settlement_position of respondent_bears, claimant_bears, shared_position or no_position. The position is a lookup, so a caller cannot supply it, and SETTLEMENT_POSITION_RECOMPUTE is the gate that says so.

ATTRIBUTION_INTEGRITY reverifies the referenced fault attribution receipt in full, every signature and every one of its own gates, on each mint and each verify. That is why this instrument is slower than its neighbours. A recovery position that trusted a handed in attribution would be worth nothing. ALLOCATION_PRECEDENCE then requires the table digest to have been committed strictly before the loss instant, and fails closed otherwise, so a table written once the loss is known produces no position at all.

An indeterminate attribution maps to no_position. The receipt does not fill that silence. Party identifiers stay out of the signed body as keyed pseudonyms, so this object can be handed to an intermediary without naming either side.

What it does not prove, in plain words. It does not say any amount is owed, that anybody will pay, that the table is enforceable, or that a contract exists at all. Whether a position turns into money is decided by the agreement between the parties and by nothing on this page. The boundary, verbatim from the schema. This receipt attests only that a named observer recomputed a settlement position between two named parties from one named fault attribution outcome and a precommitted allocation table whose digest was committed before the loss instant. It does not attest that any amount is owed, that any party will pay, that the allocation table is enforceable, or that any contract exists between the named parties. Whether the recomputed position entitles anyone to payment is decided solely by the parties' own agreement.

Count outcomes for one operator over a window, and suppress anything too small to publish

Hand it a set of fault.attribution receipts and a window. It verifies every receipt in the set, keeps the ones naming the same operator pseudonym inside the window, and buckets them by outcome class: single_party, shared, no_violation_found, indeterminate. Every count is recomputed at OUTCOME_BUCKET_RECOMPUTE. The operator is carried as a keyed pseudonym derived per operator per window, so the same operator in two windows does not link, and NO_OPERATOR_IDENTITY_LEAK is a gate rather than a promise.

SMALL_GROUP_SUPPRESSION holds a floor. A bucket below five is not reported at all, only counted into a suppressed total, and the schema refuses a reported bucket under five even if the body declares a lower floor. When nothing clears the floor, the receipt reports nothing and still verifies, which is the correct answer rather than a failure.

coverage_class is a fixed constant, supplied_set_only. The receipt states in its own signed body that it can speak only about the receipts it was handed. That is the honest limit of any track record built from evidence rather than from a private database, and it is written into the object instead of into a footnote.

What it does not prove, in plain words. It does not say the supplied set is complete or that an omitted outcome does not exist. It does not say the operator is well or badly run and it predicts nothing about the next transaction. No registration, pricing or admission decision is justified by it. It discloses no operator identity, no counterparty and no amount. The boundary, verbatim from the schema. This receipt attests only that a named observer verified the supplied fault attribution receipts, counted the ones that name one keyed operator pseudonym inside a committed window, and reported those counts by outcome class with no bucket below the stated floor. It does not attest that the supplied set is complete, that any omitted outcome does not exist, that the operator is well or badly run, that the record predicts anything, or that any registration, pricing, or admission decision is justified by it. It discloses no operator identity, no counterparty, and no amount.

Compare two records without either side handing over its logs

Each side commits a keyed digest over the same declared list of fields, at a named cursor and a named instant, signed by its own registered attestor key. The service recomputes the comparison at COMMITMENT_EQUALITY_RECOMPUTE and returns match, divergence or window_exceeded. No balance, no holder, no account identifier and no field value enters the signed body, enforced by NO_RAW_STATE_LEAK.

ATTESTOR_KEY_DISTINCTNESS refuses the obvious shortcut. One signer cannot produce both attestations, and the key that issues the receipt cannot also be named as an attestor, so nobody vouches for their own half. OBSERVATION_WINDOW_TOLERANCE and TIME_ANCHOR_DRIFT_BOUND then handle the case where the two snapshots were taken too far apart to compare, and the result is window_exceeded rather than a false match.

Now the part that makes it usable between parties who do not trust each other. When the two records diverge, the receipt reports the divergence and refuses to say which one is right. It assigns no fault. Two adversaries can both sign up to an instrument that cannot be pointed at either of them, which is the only reason either of them would.

What it does not prove, in plain words. It does not say either committed digest is a correct digest of the record it names, because checking that needs read access this receipt does not grant. It does not decide which side is right when the two disagree, allocates no fault, and does not settle or reverse anything. A window_exceeded outcome means only that the two observations were too far apart to be decisive. The boundary, verbatim from the schema. This receipt attests that two named records, each observed at a named cursor and at a named instant, and each committed by a distinct registered attestor key to a keyed digest computed over the same declared list of fields, produced the comparison outcome that this service recomputed from those two committed digests and those two instants against the declared window tolerance. It does not disclose any position, balance, holder identity, or account identifier. It does not attest that either committed digest is a correct digest of the record it names, because confirming that requires read access which this receipt does not confer. It does not decide which record is correct when the two records diverge, assigns no fault to either operator, does not decide whether the underlying settlement, transfer, or register update was proper, and does not effect or reverse any settlement. A window_exceeded outcome records only that the two observations were too far apart for the comparison to be decisive.