VERIFY.md

Verify AML without trusting AML

SHIPPED verification entry point.

The fastest way to challenge the public AML witness contract is to verify the same artifact in your own runtime.

Immutable contract target

Do not implement a vague label such as "AML verifier v1." Target the exact published snapshot:

snapshot_id: aml-verifier-contract-2026-09-08-01
source_commit: b1ff5a87c7b19ae6338503a58ab6257a5b2add0b

Snapshot: protocol/verification-contract-v1.json

The source commit is the immutable historical anchor for the exact locked path set.

One command

Implement the tiny CLI contract in protocol/aml-verifier-cli.md, then run:

node scripts/run-verifier-conformance.mjs -- your-verifier

The harness requires:

golden witness       -> PASS
tampered receipt     -> FAIL
tampered challenge   -> FAIL
expired challenge    -> FAIL

Canonical artifact

independent/python/witness-vector.json

Public contracts

• protocol/verification-contract-v1.json
• protocol/aml-verification-contract-snapshot.schema.json
• protocol/aml-verifier-implementation-claim.schema.json
• protocol/aml-witness-bundle.schema.json
• protocol/aml-browser-evidence.schema.json
• protocol/aml-verification-challenge.schema.json
• protocol/aml-session-attestation.schema.json
• protocol/sorted-json-v1.md
• protocol/aml-verifier-cli.md

Contract evolution without rewriting history

Machine-readable evolution surfaces:

• protocol/verification-contract-catalog.json
• protocol/verification-contract-lineage.json
• protocol/aml-verification-contract-migration.schema.json

Human guides:

• docs/CONTRACT_EVOLUTION.md
• docs/HISTORICAL_VERIFICATION.md
• docs/CONTRACT_MIGRATION_CHECKLIST.md

Current lineage contains one snapshot and zero migrations. That is intentional. Future snapshots must publish an explicit migration edge and may not silently reinterpret old artifacts under the old snapshot.

Reference implementations

• Browser / JavaScript
• Python standard library
• Go standard library
• HTTP reference service

Each reference implementation now publishes an aml-verifier-implementation-claim/1 bound to the same immutable contract snapshot.

All are maintained inside this repository and do not count as independent external witnesses.

Claim your implementation precisely

Generate a machine-readable claim:

node scripts/create-verifier-implementation-claim.mjs \
  --implementation-id my-verifier \
  --implementation-version 0.1.0 \
  --runtime rust-1.90 \
  --source-url https://github.com/example/my-verifier \
  --command './my-verifier --now 2030-01-01T00:05:00Z bundle.json' \
  --external true

A claim says what you target. It does not prove conformance.

External evidence

Current machine-readable external witness registry:

WITNESSES.json

The registry intentionally remains empty until reproducible evidence maintained outside aruintelligence/aml-core exists.

Submit a result through GitHub Issue #17, Issue #18, the External verifier report template, or the External verifier implementation claim template.

Claim boundary

A successful reproduction is project-defined interoperability evidence. An implementation claim is a compatibility declaration. A migration classification describes behavior between project snapshots. None of these is certification, standards-body approval, official trademark authorization, proof of institutional independence, or proof that the underlying declared intent/scores are objectively true.