# Treasury Payment Release Sealed Evidence Bundle Manifest

Version: 1.0
Published: 2026-07-28
Scope: one synthetic treasury payment-release Process run

This manifest defines the contents of a Sealed Evidence Bundle for one governed treasury payment
release. It uses synthetic identifiers and tokenized payment references. An organisation should
replace every example reference, retention period, legal basis, authority rule, and screening
source with its approved local contract.

## 1. Bundle identity

- Bundle ID:
- Process:
- Execution ID:
- Correlation ID:
- Organisation reference:
- Environment:
- Jurisdictions:
- Retention class:
- Legal hold:
- Created at:
- Created by:
- Manifest digest:
- Merkle root:
- Manifest signature (SEK, service key):
- Manifest signature (TEK, tenant key):
- Key set reference (`keys/jwks.json`):

## 2. Ordered events

| Order | Event | Required fields or result | Artifact reference |
| --- | --- | --- | --- |
| 1 | Payment request received | Source identity, channel, requested action, payer, payee, beneficiary, accounts, jurisdictions, currency, amount, purpose, requested time | `payment-request.json` |
| 2 | Source authenticity checked | Signature, message authentication, source digest, approved template, required-field result | `source-authenticity.json` |
| 3 | Agent authority checked | Requester, delegated user, service identity, agent, accountable owner, Release, tools, purpose, amount, environment, Data Boundary, expiry | `authority-decision.json` |
| 4 | Sanctions and watchlists screened | Applicable jurisdictions, lists, list versions, retrieval times, digests, screened parties, countries, banks, result, match evidence | `sanctions-screening.json` |
| 5 | Payment controls evaluated | Duplicate, counterparty, data-quality, anomaly, velocity, cutoff, amount, aggregate, currency, and route results | `payment-control-results.json` |
| 6 | Policy decided | Policy ID and version, digests, `allow`, `warn`, `require_approval`, or `block`, matched rules, reason codes | `policy-decision.json` |
| 7 | Human decision recorded when required | Decision Request, roles, maker-checker result, evidence digest, reviewer, decision, reason, expiry | `approval-decision.json` |
| 8 | Bound release submitted when permitted | Tool and version, destination, arguments digest, idempotency key, request time | `payment-rail-request.json` |
| 9 | Bank or rail outcome recorded | Accepted, rejected, pending, settled, returned, or unknown status; reference; before and after digests | `payment-rail-receipt.json` |
| 10 | Business outcome reconciled | Achieved, failed, rolled back, recalled, returned, or unresolved status; incident or compensation reference | `business-outcome.json` |
| 11 | Lineage and integrity sealed | Ordered event IDs, artifact digests, privacy treatment, record hash, signature, verifier, verification result | `audit-event.json` |

## 3. Synthetic sample runs

- [Approved maker-checker release](https://kla.digital/downloads/treasury-payment-release-approved-sample.json):
  sanctions and watchlist screening returns clear, the illustrative EUR 125,000 amount crosses a
  local maker-checker band, a synthetic senior treasury officer approves before expiry, and the
  synthetic bank gateway returns an acceptance receipt.
- [Sanctions block](https://kla.digital/downloads/treasury-payment-release-sanctions-block-sample.json): a potential
  sanctions match returns `block`; the audit event contains zero tool calls and execution remains
  `not_started`.

The figures, identities, bank gateway, and outcomes in both records are synthetic. They carry no
regulatory threshold or real payment instruction.

## 4. Public contract

- [AI Agent Audit Log Schema reference](https://kla.digital/resources/ai-agent-audit-log-schema)
- [JSON Schema draft 2020-12 contract](https://kla.digital/ai-agent-audit-event/v1/schema.json)
- [Complete public example](https://kla.digital/ai-agent-audit-event/v1/examples/complete-execution.json)
- [Denied public example](https://kla.digital/ai-agent-audit-event/v1/examples/denied-action.json)

No standalone verifier binary is published separately from this contract. Recompute every check
below directly from the published JSON Schema and the canonicalization, hashing, and signature
algorithms it declares (RFC 8785 JCS, SHA-256, Ed25519 for individual records; ES256 for the
manifest seal below).

## 5. Offline examiner checks

An examiner can perform these checks without access to KLA or the payment system:

1. Validate each `audit-event.json` against the published JSON Schema.
2. Canonicalize the signed payload with RFC 8785 JSON Canonicalization Scheme rules.
3. Recompute the SHA-256 record hash for each event.
4. Verify each event's Ed25519 signature with its declared key.
5. Verify the bundle-level seal: take `manifest.json` as published and blank
   `integrity.manifestHash` and every immudb anchor's `valueHash` before hashing — both fields are
   filled in only after signing, so hashing the file as-is does not reproduce the seal. Canonicalize
   the normalized manifest, recompute its SHA-256 digest, and confirm it matches the published
   `integrity.manifestHash` and `bundle.json`. Then verify both the SEK (service key) and TEK
   (tenant key) ES256 signatures in `manifest.jws.json` against the public keys embedded in
   `keys/jwks.json`. A record with a valid individual signature does not prove bundle membership or
   an unaltered Merkle root; only the manifest seal does.
6. Compare every artifact digest with the manifest.
7. Reconstruct the ordered request, screening, policy, approval, tool, rail, and outcome sequence.
8. Confirm that approval precedes every release effect.
9. Confirm that a pre-execution outcome (`block`, an expiry before submission, or a cancellation
   before submission) carries zero tool calls and a `not_started` execution. A post-submission
   outcome (bank or rail rejection, return, or recall) legitimately carries exactly one tool call
   and a terminal execution status; do not treat that tool call as evidence of tampering.
10. Confirm that the idempotency key maps to one payment-rail effect.
11. Confirm that payment and identity fields follow the declared tokenization or redaction policy.
12. Compare the bank or payment-rail receipt with the organisation’s independently obtained
    reconciliation record.
13. Record missing artifacts, chain breaks, failed signatures, unresolved downstream state, and
    scope limits in the examination workpaper.

## 6. Export sign-off

- Treasury operations owner:
- Sanctions compliance owner:
- Evidence owner:
- Export population:
- Omitted artifacts and reason:
- Integrity result:
- Independent verifier:
- Verification time:
- Examiner access expiry: