Not legal advice, not a negotiation service, and not a claims-processing or payment system. Every input is SUPPLIED by the caller and treated as asserted: this pack performs no lookup against a clearing system, a fails database, or a Fedwire or DTC settlement feed, and cannot establish that a declared fail, par amount, or reference rate is real. A recompute assembled from a mistaken input matches or diverges exactly as well as a true one. Matching a claimed amount means only what the cited node computed from the declared inputs, and a countersigned receipt of that recomputation means only that the signer independently reached the same execution hash, never that either counterparty has agreed to the claim, paid it, or waived a later dispute over the underlying fail. Whether a NY Fed Treasury Market Practices Group fails-charge claim is owed, and in what amount, remains a question for the two counterparties and their own back offices, never a claim this pack makes for itself.

§4 Execution Hash · Workflow Definition Anchor

execution_hash:computing…

Workflow Stage · 1 Node · Linear

1 ROOT · FAILS-CHARGE RECOMPUTE node

TMPG Fails-Charge Recompute art-575-tmpg-fails-charge-recompute

The fails-charge recompute, run independently by each counterparty over the same declared batch of fails, each with its own par amount, reference rate, and days failed, diffed against the claimed amount within a caller-declared tolerance. Every fail line carries its own MATCHES, DIVERGES, or INDETERMINATE verdict, and the batch carries one overall verdict of the same three values. Only the resulting execution hash, not any editorial reading of it, is what the two sides countersign.

MCP Call · recompute_tmpg_fails_charge

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "recompute_tmpg_fails_charge",
    "arguments": {
      "diff_tolerance_minor": 0,
      "fails": [
        {"fail_id": "fail-A", "par_amount_minor": 10000000, "reference_rate_bps": 250, "days_failed": 10, "claimed_charge_minor": 1389},
        {"fail_id": "fail-B", "par_amount_minor": 5000000, "reference_rate_bps": 0, "days_failed": 5, "claimed_charge_minor": 2083}
      ]
    }
  },
  "id": 1
}

The Bilateral Countersigned Recompute Exchange · SPEC.md §27.12

This is the pattern the pack is built around, not a second node in the chain. Both counterparties hold the same declared fails, run the same deterministic kernel over them, and each mints a signed receipt of its own run. Nothing above passes through AINumbers between the two firms: the exchange is a flat file, sent however the two firms already exchange the monthly claim, and it is verifiable offline by either side or a third party who never talked to either firm's systems.

The claiming firm assembles the month's fails as declared inputs (fail id, par amount, reference rate, days failed, claimed amount) and runs recompute_tmpg_fails_charge, sealing the resulting artifact and its execution_hash.
The claiming firm sends the failing counterparty the declared inputs and the sealed artifact, by whatever channel the two firms already use for the monthly claim. No relay and no shared registry sits between them.
The failing counterparty runs the identical kernel over the identical declared inputs on its own side. Because the kernel is deterministic, an honest recomputation over the same inputs reaches the identical execution_hash the claiming firm sealed.
The failing counterparty mints a counter_signed_receipt record (SPEC.md §27.12): subject_hash names the matched execution_hash, kernel_pin.kernel_digest names the exact art-575 kernel it verified against, role is checker, and replay_verified: true states plainly that it actually re-ran the computation rather than reviewing the number on paper.
Either firm, or a third party holding both the sealed artifact and the receipt, can recompute the execution hash from the declared inputs and confirm it matches subject_hash, then verify the receipt's own signature, entirely offline.

What the receipt says, exactly: a counter-signed receipt states one fact, that both parties independently recomputed and signed the same result. It does not say, and must never be read to say, that either party owes or agrees to the claim, that the matter is closed, or that a dispute over the underlying fail, its reference rate, or its day count is foreclosed. A matching recomputation is evidence about the arithmetic. What either firm chooses to do with that evidence, pay the claim, dispute the reference rate, or escalate through their own trading relationship, stays outside this pack.

Illustrative counter_signed_receipt output_payload · SPEC.md §27.2 / §27.12 shape, not a live signer

{
  "record_type": "counter_signed_receipt",
  "role": "checker",
  "subject_hash": "sha256:<the execution_hash both firms independently reached>",
  "kernel_pin": { "kernel_digest": "sha256:14e3887cf72bab31d7ba429fce3f50695fd92a5bf06a7db441520862bfd55efc" },
  "replay_verified": true,
  "identity": { "id": "did:key:z6Mk<the failing counterparty's own key>" },
  "timestamp": "2026-08-08T00:00:00Z"
}

The record above is itself a first-class artifact under SPEC.md §27.2: it carries its own §4 execution_hash and MUST be bound by a §16 eddsa-jcs-2022 proof to the signer's identity before it counts as conformant evidence. A bare did:key (SPEC.md §9) is sufficient to mint and verify one with no external dependency; an unsigned receipt is not evidence of anything.

Reading the Receipt · Two Subjects, One Vocabulary

The recompute names two distinct subjects and gives each its own verdict from the same three-value vocabulary, so a batch that matches overall never hides an individual fail that diverged, and one diverging fail never gets read as the whole month's claim being wrong.

Per Fail Line · Once Per fail_id

MATCHES The recomputed charge for this fail agrees with its declared claimed amount within the declared tolerance.

DIVERGES The recomputed charge falls outside the declared tolerance of the declared claimed amount for this fail. The receipt records the delta; what caused it, a wrong reference rate, a wrong day count, or a genuine dispute, is a question for the two counterparties.

INDETERMINATE This fail carries no declared claimed amount to diff against, so no match or divergence could be determined for it. Never read as a pass.

Overall Batch · Once Per Claim Run

DIVERGES At least one fail line in the batch diverges. The overall verdict is never softened by fails that matched.

INDETERMINATE No fail diverges, but the declared tolerance, the batch itself, or at least one fail's claimed amount was absent, so the batch cannot be called a clean match.

MATCHES Every fail in the batch carries a declared claimed amount and every one agrees within the declared tolerance.

no verdict of its own The counter-signed receipt carries no MATCHES, DIVERGES, or INDETERMINATE of its own. It attests only that the signer's recomputation reached the same execution_hash as the artifact it counter-signs, whatever that artifact's verdict was.

Standing Context · Dated Observations

The NY Fed Treasury Market Practices Group's fails-charge trading practice (2016 revision), as read on 2026-08-08, sets the formula this pack recomputes and describes the fails-charge claim as a bilateral figure the non-defaulting party presents to the failing counterparty. Confirm current practice text at newyorkfed.org before relying on a computed figure for a live claim. This pack makes no TMPG or NY Fed endorsement claim.

SPEC.md §27.12, as landed 2026-08-08, defines the counter-signed receipt's shape: the counter_signed_receipt record type, the checker role, and the optional kernel_pin and replay_verified sibling fields. The section states its own vocabulary ban normatively: neither the record nor any copy describing it may use language implying legal or economic closure to describe what it proves.

The pack declares no regulatory basis of its own. It produces a recomputation receipt and, where both counterparties choose to exchange one, a countersigned record of that recomputation; it does not compute, file, or negotiate the underlying fails-charge claim on either firm's behalf.

The exchange itself, the flat file carrying the sealed artifact and the countersigned receipt between the two firms, follows no AINumbers-operated relay or registry. Either firm can verify the bundle offline, and so can a third party holding it, without contacting either firm's own systems.

Export Workflow Artifact

Download a §4-compliant workflow artifact with execution hash and step definition. Hash is deterministic over canonical {policy_parameters, output_payload} per RFC 8785/JCS.

TMPG Fails-Charge Claim Pack