# AML alert-triage evidence manifest

Version: 1.0

Published: 28 July 2026

Owner: ____________________

Alert ID: ____________________

Case ID: ____________________

Execution ID: ____________________

Use this manifest to define and verify one evidence package for an AML alert-triage disposition.
The organisation owns the agent, case process, legal analysis, controls, retention schedule, and
evidence selection.

## 1. Package scope

- Transaction-monitoring system:
- Case system of record:
- Agent identity and Release:
- Accountable financial-crime owner:
- Alert detection time:
- Run start and end:
- Proposed action:
- Final disposition:
- Jurisdiction and legal scope:
- Data Boundary:
- Export purpose and recipient:

## 2. Required package contents

Approval, tool, and downstream-effect evidence depends on the terminal policy path. Write
`N/A (blocked)` in the Included column when policy blocked the request before that stage. For an
executed request, include the applicable approval record and execution evidence described below.
Do not leave a conditional row blank.

| Item | Required fields | Evidence reference | Digest | Included |
| --- | --- | --- | --- | --- |
| Manifest | package ID, alert/case/run scope, created time, exporter, retention class |  |  | [ ] |
| Audit event(s) | schema version, envelope, actors, action, policy, approval when required, tools, execution |  |  | [ ] |
| Source lineage | alert receipt, source references, query times, source versions, freshness |  |  | [ ] |
| Recommendation | summary, risk indicators, uncertainty, proposed disposition, rationale |  |  | [ ] |
| Policy record | policy ID/version/digest, inputs digest, outcome, matched rules, reason codes |  |  | [ ] |
| Approval record (conditional) | required for `require_approval`: request, expiry, required role, evidence digest, reviewer, decision, time; `N/A (blocked)` for a terminal block |  |  | [ ] / N/A |
| Tool receipt (conditional) | required when execution occurs: tool/version, destination, arguments digest, idempotency key, status, result; `N/A (blocked)` for a terminal block |  |  | [ ] / N/A |
| Downstream effect (conditional) | required when execution occurs: effect reference, before/after state digests, business outcome; `N/A (blocked)` for a terminal block |  |  | [ ] / N/A |
| Recovery record | incident, compensation, Rollback, appeal, override, or residue where present |  |  | [ ] |
| Integrity material | artifact hashes, record hash, Ed25519 key ID, signature, verification |  |  | [ ] |
| Privacy record | classification, redactions, omissions, access policy, export handling |  |  | [ ] |

## 3. Event order

Record stable event identifiers in the order a reviewer should reconstruct:

1. Alert intake: ____________________
2. Agent recommendation: ____________________
3. Policy evaluation: ____________________
4. Decision Request and reviewer decision, when required: ____________________
5. Governed tool call: ____________________
6. Downstream case effect: ____________________
7. Evidence seal and export: ____________________

Prior blocked or superseded actions remain in lineage:

| Event ID | Proposed action | Outcome | Reason code | Superseded by |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

The synthetic reference provides this minimal, independently checkable chain:

1. [`aml-alert-triage-sample-audit-event-01-blocked-autoclose.json`](./aml-alert-triage-sample-audit-event-01-blocked-autoclose.json)
   records sequence 5, event
   `evt_aml_synthetic_blocked_autoclose_20260728_01`, and a blocked auto-close with no tool call.
2. [`aml-alert-triage-sample-audit-event.json`](./aml-alert-triage-sample-audit-event.json)
   records sequence 6, event
   `evt_aml_synthetic_escalated_disposition_20260728_02`, and the approved escalation-disposition
   write. Its `previous_event_hash` is
   `sha256:05dceff936064f1236dfcd80bd7e9f7f466918549031ec725a7653db05fee645`,
   which equals event 01's `record_hash`.

The records share one correlation ID (`corr_aml_synthetic_20260728_01`) across the blocked
attempt and its replacement, each with its own execution ID
(`run_aml_synthetic_20260728_01` and `run_aml_synthetic_20260728_02`). Their lineage arrays
contain only these published event IDs.

## 4. Artifact inventory

| Artifact ID | Type | Producer | Created at | Content digest | Confidentiality |
| --- | --- | --- | --- | --- | --- |
|  | Alert source receipt |  |  |  | Restricted |
|  | Case-context snapshot |  |  |  | Restricted |
|  | Agent recommendation |  |  |  | Restricted |
|  | Policy decision |  |  |  | Restricted |
|  | Reviewer decision |  |  |  | Restricted |
|  | Tool receipt |  |  |  | Restricted |
|  | Downstream state confirmation |  |  |  | Restricted |

## 5. Approval binding

- Requester and maker identities:
- Required reviewer role:
- Reviewer identity and role snapshot:
- Presented-evidence digest:
- Bound action, parameters, destination, and case version:
- Requested at:
- Expires at:
- Decided at:
- Decision and reason:
- Revalidation reference before execution:

## 6. Downstream outcome

- Case system destination:
- Idempotency key:
- Tool status:
- Effect reference:
- Before-state digest:
- After-state digest:
- Expected business outcome:
- Observed business outcome:
- Unresolved residue:
- Incident or Rollback reference:

## 7. Redactions and omissions

List every field or artifact withheld from this export. Record a reason and authority so the
recipient can distinguish an intentional omission from missing evidence.

| JSON pointer or artifact | Treatment | Reason | Authority | Reversible token reference |
| --- | --- | --- | --- | --- |
|  | Redacted / tokenized / omitted |  |  |  |

Confirm:

- [ ] Customer identity and account data follow the export purpose and recipient boundary.
- [ ] SAR/STR material and information revealing its existence remain in the restricted perimeter.
- [ ] Customer-facing and out-of-perimeter channels received no investigation content.
- [ ] Export logs record the recipient, purpose, time, and selected evidence.

## 8. Retention and access

- Retention rule and source:
- Retention start:
- Minimum retention end:
- Maximum retention or deletion ceiling:
- Legal hold:
- Legal-hold authority and review:
- Access policy:
- Approved recipients:
- Deletion or disposition authority:
- Next access review:

Reconcile applicable retention minima, privacy or data-minimisation maxima, and legal holds, then
retain the record only for the resulting lawful period. Relevant minima can include the EU AI Act
Article 26(6) six-month floor for deployer-controlled logs and, for a US bank SAR, the five-year
period in 31 CFR § 1020.320(d), where each duty applies. Record the authority used to resolve any
conflict. Do not default to the longest schedule when an applicable rule sets a retention ceiling.

## 9. Recipient verification

For the two-file synthetic reference, a recipient can perform these checks from the published
records:

- [ ] Validate both records against the public AI Agent Audit Log Schema.
- [ ] Recompute each canonical audit-event hash.
- [ ] Verify each Ed25519 signature with its stated public key.
- [ ] Confirm both records share the stated correlation ID, use their own distinct execution ID
      (`run_aml_synthetic_20260728_01` and `run_aml_synthetic_20260728_02`), and use sequences 5
      and 6.
- [ ] Confirm event 01 has no `previous_event_hash` and event 02's `previous_event_hash` equals event
      01's `record_hash`.
- [ ] Confirm the lineage arrays contain only the two published event IDs in their observed order.
- [ ] Confirm event 01 binds `aml.alert.close` to alert `ALRT-SYN-77214` and records `block`,
      `AML_ELEVATED_RISK_REVIEW`, `AML_AMOUNT_REVIEW_25000`, `AML_AUTOCLOSE_LINKED_CASE_OPEN`, no
      approval, no tool call, and `execution.status: not_started`.
- [ ] Confirm event 02 records only its `require_approval` rules, an approval before execution, one
      successful tool call, and a succeeded business outcome.
- [ ] Inspect the declared privacy treatment, embedded artifact digests, tool receipt, downstream
      effect, and state digests.
- [ ] Record any unsupported assertion or missing material.

The two files do not publish the source artifacts or access to the synthetic case system. A
recipient cannot independently recompute the embedded artifact digests or confirm the target-system
state from these files alone.

Verifier: ____________________

Verification time: ____________________

Verdict: Pass / Fail / Qualified

Findings and limitations:

## 10. Synthetic reference

The downloadable
[`aml-alert-triage-sample-audit-event-01-blocked-autoclose.json`](./aml-alert-triage-sample-audit-event-01-blocked-autoclose.json)
and [`aml-alert-triage-sample-audit-event.json`](./aml-alert-triage-sample-audit-event.json) files
form a publication example. They use synthetic identities, organisation references, case IDs,
amounts, and artifact references. Event 01 uses the publication-only Ed25519 key ID
`aml-publication-sample-event-01-v2-2026-07-28`; event 02 uses
`aml-publication-sample-event-02-v3-2026-07-28`. The distinct keys illustrate signing-key rotation
between consecutive governed events. The records demonstrate schema validation, individual
integrity verification, and a genuine two-event hash link. They do not describe a deployed customer
control.