An AML-related status is only useful when the checked rule, source trail, and action boundary are visible together.
AML Status
The status is only useful when a reader can see what was checked and what the system cannot do.
This page shows an AML status record without turning it into a compliance claim. It explains the rule, the source trail, the planner limit, and the parts that stay local.
What this showsAn AML status can be checked and explained without giving the system approval, filing, wallet, trade, or deploy power.
Data representation
Read this as a record, not a claim.
The page is strongest when the reader can see the signal, the source trail, the record, the missing context, the next human question, and the boundary.
A redacted reader status record, source summary, check categories, and explicit outside-action refusal.
A status snapshot with visible claims, freshness checks, source references, and explicit outside-action refusal.
Private logs, customer data, employer data, confidential policy, and any real filing or approval context.
Which missing field would a human need before treating the status as operationally meaningful?
The planner can prepare a proposal record. It cannot approve, file, trade, deploy, enforce, or execute.
A status row has to show its work.
The AML status contract only trusts a row when the source, counts, rule coverage, and freshness checks are present.
AML status contract summaryThe planner can prepare a note. It cannot act.
Every compliance gate keeps action approval set to false. In simple words: this can prepare a proposal, but it cannot approve, file, trade, deploy, or execute.
Private planning endpoint, not published on the public pageThe record shape comes before the public claim.
Timestamped snapshots and checksum sidecars support the record; this page shows only the summary needed to understand the status.
Private operations record with timestamped snapshot, latest alias, and checksum sidecar What is visible
Reader-safe claims
- An AML status row is useful only when source coverage, counts, rule coverage, and freshness are visible together.
- Planning outputs keep outside action set to false on every public-facing branch.
- Private records keep checksums and latest snapshots locally; the public page shows only the summary record and clear limit.
- The public page is a status record, not an operational compliance product.
What stays bounded
Not an execution system
- Outside action allowed: false
- KYC approval allowed: false
- Wallet or trade movement allowed: false
- Report filing allowed: false
- Deployment allowed: false
Public wallet source records
Public blockchain watching belongs here only as source context.
Popular public wallet addresses can keep the AML learning layer current because public blockchains show movements that people already discuss. The safe version records the public source, movement type, pattern question, and missing context. It does not turn the status page into an accusation, filing decision, trade recommendation, or external submission.
Source trail
The record has a source trail. It is not just a claim.
Readers can see the source summary. The reader-facing page shows the summary, not implementation details.
Verification records
What was checked locally
The page records check categories and results. The page records check categories and results, not module internals.
The record stores the verification summary, not implementation details.
The public record stores the check category and result only.
Next hardening
Where this should get stronger
- Keep public AML records summary-first and raw-command-free.
- Keep detailed records out of the reader-facing summary unless a redacted version is prepared.
- Review new status records for instruction text, account data, and operational detail before publishing.
Short version
What this means
The AML status page keeps the simple order: show the source, show the check, show the limit, and do not jump from a local record to a real-world decision.