Follow one business event from the front office to the back office

Run one payments day end to end and leave evidence a regulator and an auditor can both check.

1. Validate a synthetic pain.001 with pain001_validate; fix the reported defects in the input and re-run until clean. Record the hash.
2. Parse a synthetic camt.053 with camt053_parse, then recon_match the statement lines against the pain.001 batch. Report matched / unmatched with reasons.
3. Run verify_address_migration_batch on the beneficiary addresses to check ISO 20022 structured-address readiness.
4. Predict fails with predict_settlement_fail on today's trades, price the CSDR penalties with calculate_csdr_penalty, and model buy-in exposure with model_buy_in_exposure. Then run run_t1_readiness_diagnostic and list the top three gaps.
5. Call build_evidence_pack over every hash from steps 1-4 with the kernel_digests from chaingraph.json.
6. On helmd: catalog.search "2052a", workflow.dry_run the daily classify pack, artifact.verify it, and note that the export needs a human consent ticket; do not request one.
7. Anchor the evidence pack digest with anchor_stamp on OpenTimestamps. Give me the ledger link for the pack and a one-page day-end note: counts, exceptions, penalties, T+1 gaps, and how each number is re-verified without contacting us.
Call shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {"policy_parameters": { ... }}; flat arguments are discarded by schema validation. If a named tool is not in your tool list, call call_tool with { "name": "<tool>", "arguments": { … } }. It runs the same validation and returns the same receipt.
GPU note: the verify_address_migration_batch tool computes in your browser, so the MCP endpoint returns no execution_hash; export the Policy Mandate artifact the page produces and pass that full artifact to verify_execution_hash as claimed_hash.

Follow one securities trade from instruction to settlement and leave a receipt any reviewer can re-check.

1. Lint a synthetic sese.023 settlement instruction with lint_securities_settlement_message (schema conformance, mandatory fields, ISIN checks); fix the reported defects in the input and re-run until clean. Record the execution hash.
2. Lint the matching sese.024 status advice the same way and confirm the status progression the instruction and the advice describe together.
3. Classify the post-trade timings with classify_t1_posttrade_timing on declared trade dates and market cut-offs. List every step that breaches its cut-off under the T+1 regime and the margin each step has left.
4. Score the trade's fail probability with predict_settlement_fail from anonymized configuration features (SSI match status, instrument liquidity tier, counterparty fail-history band, deadline proximity). Report the score and the drivers behind it.
5. Seal the run with build_session_receipt over the hashes from steps 1 to 4, then call verify_execution_hash (send each receipt's execution_hash as claimed_hash) so every number re-verifies from the receipt alone.
Deliverable: lint verdicts, the cut-off breach list, the fail score with its drivers, the ledger link, and one sentence on what the receipts prove (the declared synthetic inputs were validated, classified, and scored as given) and what they do not prove (no real client data, no settlement outcome, no compliance determination).
Call shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {"policy_parameters": { ... }}; flat arguments are discarded by schema validation. If a named tool is not in your tool list, call call_tool with { "name": "<tool>", "arguments": { … } }. It runs the same validation and returns the same receipt.

Walk one synthetic purchase through the full AP2 evidence chain.

1. Call draft_ap2_mandate_credential for a synthetic cart (two line items, a spend cap, an expiry). Record the credential id.
2. Call validate_ap2_mandate_credential on the draft. Confirm the signature structure and the cap/expiry fields; record pass/fail.
3. Tamper-test: change one line item's price in the signed cart, re-validate, and confirm the validator rejects it. Revert.
4. Call build_ap2_cartmandate_hashchain over the cart events. Record the chain root.
5. Call validate_ap2_mandate_chain on the chain. Record pass/fail and which links are covered.
6. Call simulate_x402_flow for the settlement, then correlate_ap2_cartmandate_x402 to bind the settlement to the mandate chain. Record the correlation verdict.
7. build_session_receipt over every hash; give me the ledger link.
8. Write the note for the payments team: which claims the chain proves (mandate integrity, cart binding, settlement correlation), what it does not prove (merchant delivery), and the ledger link.
Call shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {"policy_parameters": { ... }}; flat arguments are discarded by schema validation. If a named tool is not in your tool list, call call_tool with { "name": "<tool>", "arguments": { … } }. It runs the same validation and returns the same receipt.

Check a tokenized treasury trade where each party is supposed to see only its leg.

1. Call validate_dtc_tokenized_treasury on a synthetic DTC-custodied issuance (CUSIP, par, coupon, token wrapper). Record the structural verdict and any flagged field.
2. Build the synthetic DvP: two parties, each with a leg, payment-versus-payment.
3. Call validate_canton_selective_disclosure. Confirm party A's attestation reconciles while exposing only A's leg, and the same for B.
4. Privacy test: attempt to read the counterparty leg from A's view; confirm the tool returns nothing. Quote the returned shape.
5. Run the chain wholesale-settlement-cross-network-dvp with run_chain. Record the composed verdict and execution_hash.
6. build_session_receipt over the two validations and the chain; give me the ledger link.
7. Write the note for the settlement desk: what reconciled, what each party can see, and the ledger link, so both parties verify the same receipt without sharing books.
Call shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {"policy_parameters": { ... }}; flat arguments are discarded by schema validation. If a named tool is not in your tool list, call call_tool with { "name": "<tool>", "arguments": { … } }. It runs the same validation and returns the same receipt.

Follow one derivative trade through the EMIR Refit reporting checks and leave a receipt a supervisor can re-check.

1. Validate a synthetic auth.030 trade report with validate_emir_trade_report (action type, both 20-character LEIs, UTI, UPI, notional, currency); fix the reported field defects in the input and re-run until clean. Record the execution hash.
2. Pair the two counterparties' reports by UTI with reconcile_emir_pairing over a declared matching-field set within a per-field tolerance. List every field that lands outside tolerance with its two reported values.
3. Correct each out-of-tolerance field in the input, re-run reconcile_emir_pairing, and keep the before/after exception list until the declared matching-field set comes back clean.
4. Seal the run with build_session_receipt over the hashes from steps 1 to 3, then call verify_execution_hash (send each receipt's execution_hash as claimed_hash) so every number re-verifies from the receipt alone.
Deliverable: the validation verdict, the before/after pairing exceptions, the ledger link, and one sentence on what the receipts prove (the declared synthetic reports were validated and paired as given) and what they do not prove (no real counterparty data, no filing, no regulatory determination).
Call shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {"policy_parameters": { ... }}; flat arguments are discarded by schema validation. If a named tool is not in your tool list, call call_tool with { "name": "<tool>", "arguments": { … } }. It runs the same validation and returns the same receipt.

Prove a travel-rule batch and leave an audit path that does not depend on your systems.

1. Build a synthetic batch of 20 transfers with complete originator/beneficiary fields and 3 deliberately defective ones.
2. Call validate_tfr_travel_rule_batch. Record per-transfer verdicts; confirm exactly the 3 defectives fail and quote their defect codes.
3. Call verify_merkle_batch on the batch's audit root with one inclusion proof per defective transfer. Confirm each proof resolves to the root.
4. Negative test: swap two transfers in the batch, re-verify the inclusion proofs, confirm they fail against the same root. Revert.
5. Run the chain mica-travel-rule with run_chain for the composed regulatory verdict. Record execution_hash.
6. build_session_receipt over the batch validation and Merkle checks; give me the ledger link.
7. Write the note for compliance: batch size, defect classes, the root, and the ledger link, so the receiving VSP re-verifies inclusions without asking for your files.
Call shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {"policy_parameters": { ... }}; flat arguments are discarded by schema validation. If a named tool is not in your tool list, call call_tool with { "name": "<tool>", "arguments": { … } }. It runs the same validation and returns the same receipt.

Run one regulatory reporting cycle and leave receipts a reviewer can re-check.

1. Compare this period's regulatory report instance with the prior period using explain_regrpt_variance. Report absolute and relative movement per line item against the declared materiality threshold, and name the lines that moved most.
2. Attest the daily reconciliation duty with attest_daily_reconciliation over a caller-declared population. The attestation states the duty was discharged over that population; the match computation itself stays outside it.
3. Map the FFIEC 031 Schedule RC-R components with map_call_report_schedule_rcr from declared CET1, additional Tier 1, and Tier 2 capital, total risk-weighted assets, and total leverage exposure. Return the mapped ratios. The sibling tool map_call_report_schedule_rc maps the Schedule RC balance-sheet lines the same way if the cycle needs them.
4. Seal the run with build_session_receipt over the hashes from steps 1 to 3, then call verify_execution_hash (send each receipt's execution_hash as claimed_hash) so every number re-verifies from the receipt alone.
Deliverable: the variance table, the attestation receipt, the capital mapping, the ledger link, and one sentence on what the receipts prove (the declared inputs were processed as given) and what they do not prove (no filing submission, no capital adequacy conclusion).
Call shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {"policy_parameters": { ... }}; flat arguments are discarded by schema validation. If a named tool is not in your tool list, call call_tool with { "name": "<tool>", "arguments": { … } }. It runs the same validation and returns the same receipt.