Dispute evidence

The card networks' dispute rules were written for a human who clicked. When an agent buys something and a person later disputes it, a merchant holds signals no dispute form has a box for: which agent acted, whose authority it acted under, when that authority was granted, and which named checks a gate ran before the money moved. Disputes are already adjudicated internally against a signed policy. What was missing is the packaging step, and this is that step and nothing more.

The bundle

Assembly is reporting, not argument. Fields are copied and delivery evidence is graded on the existing ladder. Nothing is inferred, nothing is defaulted, and no gap is filled: an input the caller does not hold arrives as a stated unavailability with its reason, and lands in the bundle that way. Every fact carries whether it is known or unavailable explicitly, so a consumer never has to read the value to find out.

Actor

Which agent acted, who it acted for, and how its identity was established at decision time.

Authority

The mandate, when it was granted, when it expires, the per-payment and per-period caps and the period.

Decision

The outcome, the instant, the policy hash, and the named checks that passed and that failed.

Settlement

The rail's own reference, the rail, the instant, the sum, and the enforcement hash on the receipt.

Delivery

Each item as submitted, with its declared class, the class it actually counts for, and the audit-chain reference it is anchored to.

Both the passed and the failed check lists are carried. A predicate absent from both was never evaluated, and a passed list on its own would read as "all passed".

Where an evidence item carries no description, the bundle says so rather than inventing a label. A fabricated caption on a piece of evidence is exactly the sort of small invention a reviewer would treat as a statement of fact.

The limits travel inside the file

Dispute files are exported, attached, forwarded and re-attached. The standing limits are carried inside every bundle so they cannot be separated from it.

• It does not establish that the cardholder wanted this purchase. It establishes that a payment fell inside an authority granted in advance and that a gate decided it under a disclosed policy. Desire is usually the contested fact in an agent dispute and nothing here reaches it.
• It does not establish that the person who granted the authority is the person named on the funding instrument.
• Delivery facts are graded assertions with a stated admissibility class, not findings. A class is how strongly a claim is backed, not whether it is true.
• It claims no card network's, scheme's or regulator's evidence standard. No network rulebook is encoded anywhere, and no issuer, acquirer or arbitration body has agreed to accept this artifact.
• It is silent about payments that never entered the record. It grades what was recorded and cannot show that the record is complete.

The verdict that says do not bother

A merchant wants to know, before spending the submission and the fee and the relationship, whether what is held actually answers the reason the cardholder gave. A tool that always renders a confident-looking file teaches its operator to submit files that lose. So the strongest verdict is the narrowest of three, and probably-insufficient is a first-class result with named gaps rather than an error path.

probably_insufficient

A required fact is missing, or the record itself carries something against the presenter. Submitting it as it stands is unlikely to be worth the effort.

contested

Worth submitting, but it should not be expected to settle the matter. A reviewer can reasonably decide either way on it.

reasonably_supported

It answers the facts the reason turns on, as far as anything held in a payment record can.

Seven dispute reasons are modelled, each with the facts it requires and the facts that merely help. Damaging signals the record itself carries are reported rather than suppressed: a gate outcome that was not an allow, named checks that failed at decision time, delivery evidence below the floor the reason is assessed against, or no delivery evidence at all where delivery is the question. The operator is better off knowing before submitting than after.

The ceiling on intent

Two of the reasons, "I do not recognise this" and "I did not authorise this", turn on what a person intended, and an agent transaction cannot evidence that. Authority granted in advance shows the payment was in scope; a person can grant a scope and still not have wanted the thing bought inside it, and that gap is the entire consumer complaint.

For those reasons the verdict is capped at contested however complete the record is, and the assessment names the gap instead of talking around it. The cap is enforced in code and covered by a test, because it is the one property that must not erode under pressure to produce a better-looking output.

No rulebook is encoded

Every card network runs its own dispute process with its own reason codes, evidence categories and submission fields, and those rulebooks are licensed documents rather than public specifications. Encoding a guess at them would be the worst outcome available: a merchant would submit a file built to an invented standard, believing it was built to the real one, and would lose in a way that looks like the software worked.

So the general shape is modelled and the mapping is an injected seam an operator who holds a rulebook implements. A partial profile maps what it knows and reports the rest as unmapped. With no profile, the default reports honestly that nothing is mapped, which is the true state of affairs rather than a silent pass.

Sealed so it survives leaving the building

The file is exported as one self-contained string carrying the canonical signed bytes, the signature and the key, verifiable offline by someone who has never heard of us. It reuses the existing portable-proof and signing primitives; no second scheme is introduced and no key is held here.

Both the machine form and the narrative are projections of a single ordered list of statements, so neither can contain a fact the other does not. The narrative is signed with the data, and verification re-derives it from the statements and refuses a mismatch. "The prose says more than the data" is a detected state rather than a plausible one. The rendering happens at sealing time rather than being accepted as an argument, because a caller that could hand in its own narrative could hand in an edited one, and the signature would then attest to the edit.

valid: true   the holder of this key signed these facts and this prose,
              and the prose is the data

valid: true   does NOT mean the facts are true, and does not mean
              the file wins a dispute