Copy-paste prompts for the AINumbers suite

Grade your agentic-payments and MCP surface, fix the worst gap, prove the fix.

1. Call run_agentic_readiness_diagnostic against your deployment's public URL. Record the overall grade and the ranked gap list.
2. Call score_mcp_server_readiness on your MCP endpoint. Record the score and the failing dimensions.
3. Call lint_mcp_server_conformance on the same endpoint. Record every conformance violation with its rule id.
4. Pick the single highest-impact gap across the three reports. State what fixing it requires and who owns it.
5. Fix that one thing (or have the owner fix it). Change nothing else.
6. Re-run all three tools. Quote the before/after numbers for the one gap; leave the others untouched.
7. Give me the ledger link for the re-run session (build_session_receipt over the two diagnostic runs).
8. Write the note for your engineering channel: the three grades, the one fix, the delta, and the ledger link so anyone re-verifies the numbers without asking you.
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.

Decide whether an automated client may enter, and keep the decision receipt.

1. Capture the client's request signature headers (RFC 9421 signature-input, signature, and the webbotauth document).
2. Call verify_webbotauth_signature on the captured headers and the served webbotauth document. Record pass/fail and the key id used.
3. Call check_webbotauth_nonce_replay with the nonce and timestamp window. Record whether the nonce was seen before.
4. Call check_jwks_pinned_directory to confirm the signing key is the key the operator pinned in the directory. Record the pin match.
5. Run the chain visa-tap-agent-verification with run_chain, which composes the three checks. Record the chain verdict and execution_hash.
6. Negative test: replay step 2 with a one-byte-changed signature and confirm it fails. Quote the error.
7. Give me the ledger link for the chain receipt.
8. Write the gate note for your security log: client identity, which checks passed, the one negative test, and the ledger link. State what the gate does not cover (authorization and rate limits are your edge's job, not the signature's).
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.

Find out what your agent's spend policy actually does before a live agent finds out for you.

1. Write down the policy as you believe it is (per-transaction cap, daily cap, merchant allowlist). This is the claim you are testing.
2. Call simulate_spend_policy with 10,000 synthetic transactions spanning: under-cap, at-cap, over-cap, burst-across-midnight, and allowlist-boundary cases. Record the approve/decline counts per class.
3. Call simulate_agent_spend_policy for the agent-shaped variants (parallel requests, retry storms, currency round-trips). Record where the policy and the agent disagree.
4. Find the worst class: the transactions where the outcome contradicts your step-1 claim. Quote three examples with inputs.
5. Adjust the policy (or file the fix), re-run only the failing class, and quote the new counts.
6. Export the effective Policy Mandate your simulation ran under; record its digest.
7. build_session_receipt over the runs; give me the ledger link.
8. Write the note for treasury: what the policy really enforces, the three example transactions, the mandate digest, 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.
GPU note: the simulate_spend_policy 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.

Prove that the access decision your gate claims is the decision it made.

1. Call compute_authzen_conformance_fixture for one AuthZEN evaluation request (subject, action, resource). Record the expected decision.
2. Send the same request to your gate. Record what it actually decided. If expected and actual differ, that difference is the whole finding.
3. Call checklist_validate_definition on the checklist that defines this decision step. Record pass/fail and the definition digest.
4. Call checklist_step_receipt for the step: this binds the decision, the definition digest, and the inputs into one receipt. Record execution_hash.
5. Negative test: change the resource id in the request, re-run the step, confirm the receipt's hash changes. Quote both hashes.
6. build_session_receipt over the fixture, the definition check, and both step receipts. Give me the ledger link.
7. Write the note for the IAM review: the decision, the definition digest, the two hashes, and the ledger link, so an auditor re-verifies the gate without your help.
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.

Take one reserve attestation from PDF-trust to proof chain.

1. Call precheck_reserve_attestation on a synthetic GENIUS-style attestation (reserve assets, liabilities, custodian lines). Record every flagged field.
2. Call simulate_stablecoin_reserve with a redemption scenario (10% and 30% same-day redemption). Record the survival verdict per scenario.
3. Call calculate_mica_own_funds for the same balance sheet under the MiCA own-funds classes. Record the required amount.
4. Run the chain reserve-proof-verification with run_chain, which composes the checks into one verdict. Record execution_hash.
5. Break-test: inflate one reserve line by 1 unit, re-run the chain, confirm the verdict changes. Revert.
6. anchor_stamp the passing chain's execution_hash on OpenTimestamps.
7. Give me the ledger link for the chain receipt and the OTS receipt.
8. Write the note for the issuer's CFO: what the proof covers (arithmetic and disclosure consistency, not the existence of bank balances), the stress results, and both receipts.
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 simulate_stablecoin_reserve 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.

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.

Know your liquidation point from a deterministic model, not a dashboard screenshot.

1. Write down the position: notional, entry, leverage, funding, margin. Synthetic numbers only.
2. Call compute_perp_margin for the current state. Record the margin ratio and the maintenance threshold.
3. Call model_perp_position across a price ladder (your entry down 5/10/20/50 percent, and up). Record the liquidation price the model returns and the funding drag per rung.
4. Re-run the worst rung with funding doubled. Note how much the liquidation price moves; that sensitivity is your model risk.
5. Call verify_execution_hash (send the artifact or its hash as claimed_hash) on the worst-run output to confirm the hash is the deterministic function of its inputs. Record it.
6. build_session_receipt over the ladder runs; give me the ledger link.
7. Write the note for yourself: the liquidation price, the funding sensitivity, and the ledger link, so the scenario is reproducible after the position is long gone.
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 bridged transfer before you treat it as settled.

1. Take the synthetic CCTP v2 message attestation for the transfer (nonce, amount, source/destination domain).
2. Call validate_cctp_v2_transfer. Record the attestation verdict and the mint/destroy pair it implies.
3. Call check_linea_l2_finality_window for the source chain state. Record whether the finality window has fully elapsed and what remains exposed before it does.
4. Run the chain arc-dvp-settlement with run_chain to place the transfer in a settlement context. Record execution_hash.
5. Failure test: re-validate with the fast-transfer flag set but the finality window not elapsed; confirm the tool flags the gap. Quote the flag.
6. build_session_receipt over the checks; give me the ledger link.
7. Write the treasury note: transfer id, attestation verdict, finality status, the exposure window in minutes, 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.

One pass over four token-standard claims, each under its own receipt.

1. Call recompute_erc4626_vault_share_math on a synthetic vault (totalAssets, totalSupply, one deposit, one withdrawal). Record previewRetain/share math both directions and any rounding direction.
2. Call classify_erc1967_proxy_slot on a synthetic storage dump. Record whether the proxy slot classifies as expected and which implementation slot it points to.
3. Call calculate_erc2981_royalty for a synthetic sale. Record the royalty and the receiver; confirm rounding matches the standard's expectation.
4. Call verify_merkle_airdrop_proof for one claimed airdrop allocation against a synthetic root. Record pass/fail and the proof path.
5. Negative tests: perturb the vault's totalSupply by 1 wei and confirm the share math changes; corrupt one airdrop proof nibble and confirm it fails. Quote both.
6. build_session_receipt over all four checks; anchor the root with anchor_stamp.
7. Give me the ledger link and the OTS receipt.
8. Write the audit note: each claim, its verdict, its hash, and the two receipts, so the protocol team pins the evidence to the block they audited.
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.

Scope your MiCA CASP posture with each answer under a receipt.

1. Call run_mica_casp_fit with your synthetic service inventory (which crypto-asset services you render, to whom). Record the fit verdict per service.
2. Call assess_mica_casp_readiness for the authorization gap list. Record each gap with its class.
3. Call calculate_mica_own_funds on the synthetic balance sheet. Record the computed own-funds requirement and which of the three bases binds.
4. Call assess_mar_crypto_surveillance on a synthetic order/transaction sample. Record the coverage verdict and the flagged patterns.
5. Pick the one gap that blocks authorization first; state the evidence the reviewer will ask for.
6. build_session_receipt over the four runs; give me the ledger link.
7. Write the board note: the fit verdict, the own-funds number, the top gap, and the ledger link. Say plainly that these are deterministic self-assessments from your inputs, not a regulator's 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.

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.

One morning risk run, every number re-verifiable.

1. Call run_liquidity_stress_test on a synthetic balance sheet under a combined LCR/NSFR stress (outflow rates up, inflows haircuts). Record the survival horizon and the binding constraint.
2. Call compute_stress_test_scenarios for the scenario set. Record which scenario is worst and by how much.
3. Call compute_rwa_scenarios across the Basel RWA approaches for the same book. Record the RWA range and the approach that binds.
4. Call compute_portfolio_var for the trading book at 99/1-day, then under the worst stress path. Record both numbers.
5. Consistency check: state in one sentence whether the VaR book and the RWA book overlap, and where the models disagree.
6. build_session_receipt over the four runs. Give me the ledger link.
7. Write the morning note for the ALCO: the binding constraint, the worst scenario, the RWA and VaR numbers, and the ledger link, so any attendee recomputes the run from the same inputs without your help.
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 compute_portfolio_var 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.

Run the desk's FRTB expected shortfall through the same arithmetic a reviewer would.

1. Assemble a synthetic trading-position sample for one desk (instruments, sensitivities, liquidity horizons).
2. Call simulate_frtb_es under the IMA expected-shortfall settings. Record the ES figure and the liquidity-horizon mapping used.
3. Run the chain basel-endgame-frtb-capital with run_chain for the capital composition. Record execution_hash.
4. Cross-check: recompute ES at doubled liquidity horizons and quote the delta; this is where most desk models are thin.
5. Record which inputs drove the result: perturb the largest position 10 percent and quote the ES delta.
6. build_session_receipt over the runs; give me the ledger link.
7. Write the pre-validation note for the model-risk team: the ES figure, the horizon sensitivity, the perturbation delta, 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.

Close the quarter's CECL allowance where the numbers never leave your machine.

1. helmd catalog.search for the CECL allowance pack; record the workflow id and manifest digest.
2. helmd workflow.dry_run the pack against this quarter's synthetic loan tape. Fix any gate failure before the real run.
3. helmd workflow.run the pack. Poll helmd artifact.get for the execution_hash and per-step digests.
4. helmd artifact.verify the run against the manifest digest. State pass/fail.
5. Cross-check one number on the public worker: find_tool for the allowance or amortization tool, run the same rollforward input remotely, and compare hashes. If they differ, your local pack and the published kernel have drifted; quote both.
6. build_session_receipt over the local run and the remote cross-check; give me the ledger link.
7. Write the close note for the controller: the allowance figure, the manifest digest it came from, the cross-check result, and the ledger link. 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 synthetic loan through the four consumer checks and bind the results.

1. Write the loan facts once (amount, rate, points, fees, lien status, borrower type). Synthetic data only.
2. Call lookup_reg_z_thresholds for the current applicable thresholds. Record them; everything downstream cites these.
3. Call check_qm_points_and_fees. Record pass/fail with the points-and-fees computation shown.
4. Call test_hpml_escrow. Record whether the escrow requirement attaches and why.
5. Call classify_mla_charge_inclusion over the fee list. Record which charges count as MLA fees and the final coverage verdict.
6. Call compute_deterministic_amortization_schedule. Record the APR-consistent schedule digest.
7. Boundary test: move the loan amount 1 dollar past a threshold from step 2 and confirm the affected verdicts flip. Revert.
8. build_session_receipt over the five checks; give me the ledger link.
9. Write the note for the loan file: each verdict with its cited threshold, the boundary test, and the ledger link. State that these are deterministic rule checks against your inputs, not a compliance opinion.
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.

Put the credit model's governance evidence where an examiner can recompute it.

1. Call score_credit_default_risk on a synthetic applicant pool. Record the score distribution and the top features the model used.
2. Call assess_ai_act_conformity for the model as a high-risk system under the AI Act. Record each requirement's evidence verdict (data governance, logging, human oversight, accuracy).
3. Run the chain ai-governance-credit-ai-conformity with run_chain. Record the composed verdict and execution_hash.
4. Gap list: name the conformity items with no evidence yet and who owns each.
5. build_session_receipt over the scoring run, the conformity assessment, and the chain; give me the ledger link.
6. Write the note for the model-risk committee: the conformity status, the gap owners, and the ledger link, so the committee's evidence survives model retraining by re-running the same receipt.
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 score_credit_default_risk 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.

The daily 2052a classification, sealed before you send anything anywhere.

1. helmd catalog.search "2052a". Record the classify pack's workflow id and manifest digest.
2. helmd workflow.dry_run against today's synthetic extract. Fix gate failures; do not classify a file the gates reject.
3. helmd workflow.run. Poll helmd artifact.get for the execution_hash and per-line classification digests.
4. helmd artifact.verify against the manifest digest. State pass/fail.
5. Spot-check three classifications by hand against the instruction text; record agreement.
6. helmd evidence.export the day's bundle. Confirm it carries the manifest digest, the execution_hash, and the offline verify command.
7. Give me the bundle path and the ledger link if your deployment mirrors runs.
8. Write the daily note for the intraday-desk file: line counts, the three spot checks, the digest, and the seal. Whoever audits the submission re-verifies from the bundle, not from your word. 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.

Test the sanctions programme's mechanics against cases you control.

1. Call run_sanctions_screening_fit with your synthetic screening configuration and sample flow. Record the coverage verdict per list.
2. Call aggregate_ownership_50pct on a synthetic ownership graph containing one chain that lands exactly at 50 percent and one at 49. Confirm the tool classifies them differently and quote both paths.
3. Fuzzy-match calibration: screen a synthetic name with transposed letters and one with an honorific prefix. Record whether each hit matches and at what threshold.
4. Call classify_eccn_dual_use on one synthetic item to confirm the export-control lane is wired. Record the classification.
5. Run the chain sanctions-screening-demo (or the sanctions chain your inventory names) with run_chain. Record execution_hash.
6. build_session_receipt over the runs; give me the ledger link.
7. Write the note for the head of compliance: the 50% results, the fuzzy thresholds you set, the chain hash, and the ledger link. The calibration cases become next quarter's regression test.
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.

The first four hours of a DORA incident, with every classification step receipted.

1. Write the incident facts as known at hour zero (system, impact, detection time). Facts only; no cause speculation.
2. Call classify_dora_incident. Record the classification and the reporting clocks it starts, with their deadlines.
3. Call simulate_ict_cascade from the affected service. Record the downstream services hit and the order they fall over.
4. Run the chain dora-escalation-demo with run_chain for the composed escalation verdict. Record execution_hash.
5. Re-run the classification with detection time shifted by one hour; quote how the deadlines move. That sensitivity is what you communicate to the crisis team.
6. build_session_receipt over the classification and cascade; anchor the receipt root with anchor_stamp.
7. Give me the ledger link and the OTS receipt.
8. Write the escalation record for the incident channel: classification, clocks, cascade list, both receipts, and the one line stating which facts are confirmed versus assumed.
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 simulate_ict_cascade 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.

Triage a synthetic alert batch and seal the reasoning trail.

1. Build a synthetic batch of 50 transactions embedding three known typologies (structuring, rapid movement, round-amount pairing).
2. Call score_aml_typologies. Record the typology scores; confirm the three planted typologies outrank the filler.
3. Call detect_transaction_anomalies. Record the anomaly list and the method each was flagged by.
4. Call simulate_app_fraud_graph over the customer-payment graph. Record the fraud clusters found and their centrality scores.
5. Disagreement check: name the transactions the typology scorer and the anomaly detector disagree on; those are your review queue, not noise.
6. build_evidence_pack over the scores, anomalies, and graph digests. Give me the ledger link for the pack.
7. Write the triage note for the investigator: the review queue, the planted-typology recall, the pack link, and the one line that says every score recomputes from the same synthetic inputs.
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 score_aml_typologies 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.

Turn post-quantum anxiety into a dated, receipted plan.

1. Call run_pqc_timeline_fit with your synthetic crypto inventory (TLS endpoints, certificate lifetimes, data sensitivity classes). Record the fit verdict and the dates it assumes.
2. Call plan_tls_pki_migration for the TLS/PKI estate. Record the migration order, the hybrid periods, and the cutover dates.
3. Call classify_blockchain_quantum_risk for any chain exposure in the inventory. Record which assets are harvest-now-decrypt-later sensitive versus signature-only exposed.
4. Name the data with the longest secrecy requirement; that is what HNDL actually threatens. Quote its decrypt-by horizon versus the migration date.
5. build_session_receipt over the three runs; give me the ledger link.
6. Write the plan for the security steering group: the three phases, the HNDL priority list, the ledger link, and the assumption that the timeline tools take standard dates as inputs, so the plan re-runs when NIST dates move.
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.

Price one import schedule's CBAM exposure with every number re-computable.

1. List the synthetic import schedule: goods, CN codes, origin, quantities, per quarter.
2. Call resolve_cbam_default_value per good. Record the default embedded-emissions values used where no actuals exist.
3. Call aggregate_cbam_precursor_emissions for goods with precursor inputs. Record the aggregated values.
4. Call calculate_cbam_embedded_emissions per line. Record the totals.
5. Call model_cbam_certificate_cost across the schedule with this quarter's certificate price and the free-allocation phase-down. Record the cost range.
6. Call score_taxonomy_alignment for the optional alignment KPI. Record the score.
7. build_session_receipt over the runs; give me the ledger link.
8. Write the note for the sustainability lead: the cost range, which lines drove it, the default-versus-actuals mix, and the ledger link, so the numbers survive a supplier sending better data (re-run and the receipt updates).
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.

Provenance for one product across three regimes, one receipt.

1. Call verify_dscsa_transaction_statement on the synthetic T3 data for the pharma line. Record pass/fail and the trading-party identifiers.
2. Call validate_fsma204_cte on the food line's critical tracking events. Record which CTEs are present and which are missing for the KDE pairs.
3. Call resolve_recall_trace for both lines: given a synthetic lot, record the trace-up and trace-down paths and their terminals.
4. Call validate_dpp_data_carrier on the digital product passport carrier. Record whether the carrier resolves and what data it serves.
5. Recall drill: pick one terminal node from step 3 and confirm the trace lists every affected lot, not just the first. Quote the lot count.
6. build_session_receipt over the four checks; give me the ledger link.
7. Write the provenance note for the quality team: what each regime check covers, the recall path summary, and the ledger link, so a regulator's question is answered by re-running the receipt.
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.

Recompute a certified payroll from the raw timesheets so the certification has a hash behind it.

1. Prepare a synthetic weekly payroll: workers, classifications, hours per day, fringe payments.
2. Call recompute_certified_payroll_pwa with the synthetic data and the applicable prevailing-wage determinations. Record the computed wage rates, the underpayments flagged, and the per-worker totals.
3. Confirm the recomputation matches what was certified for the week; quote any line that differs with both numbers.
4. Call verify_execution_hash (send the artifact or its hash as claimed_hash) over the recompute output. Record the hash.
5. Negative test: change one worker's hours by one, re-run, confirm both the totals and the hash change. Revert.
6. build_session_receipt over the runs; give me the ledger link.
7. Write the note for the compliance officer: the week covered, the flagged lines, the hash, and the ledger link. The certification now points at a receipt instead of a spreadsheet.
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.

Self-attest your MCP server with receipts instead of a checkbox.

1. Call lint_mcp_server_conformance against your server endpoint. Record every violation with its rule id and severity.
2. Call score_mcp_server_readiness. Record the score, the per-dimension breakdown, and the weakest dimension.
3. Fix the conformance violations (or file them with owners). Fix nothing else this pass.
4. Re-run both tools. Quote before/after per dimension; the score delta is your attestation claim.
5. Rescan after one week without changes to confirm the score holds; that re-run is what makes it an attestation rather than a snapshot.
6. build_session_receipt over all four runs; give me the ledger link.
7. Write the self-attestation for your server's README or trust page: the score, the date, the rules checked, and the ledger link, so a client verifies the claim against the receipt rather than your wording.
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.

One audit object for a day of agent activity, framed the way an examiner asks.

1. Collect today's execution receipts (ids and hashes) from your agent sessions. Synthetic sessions are fine; the mechanics are what you are proving.
2. Call aggregate_execution_receipts over the set. Record the aggregate digest and any receipt it could not include, with the reason.
3. Call build_session_receipt over the aggregate. This is the Art. 12-style log entry: what ran, when, under which hash.
4. Call compose_ap2_prompt to render the regulator-framed summary of the aggregate. Record the prompt text it returns.
5. Completeness test: remove one receipt id from the set, re-aggregate, confirm the digest changes. Quote both digests; that sensitivity is what makes the aggregate meaningful.
6. anchor_stamp the aggregate digest on OpenTimestamps.
7. Give me the ledger link and the OTS receipt.
8. Write the examiner note: session coverage window, receipt count, the aggregate digest, both receipts, and the one line stating the log recomputes from the receipts, not from your records.
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.

Move a document from someone's laptop trust into a verifiable record.

1. Take one markdown document and its converted form (the published artifact). Synthetic or public text only.
2. Call convert_markdown_document on the source. Record the conversion digest and whether the conversion is deterministic (re-run and compare).
3. Diff the fresh conversion against the published artifact. If they differ, the published copy drifted; quote the differing lines.
4. Call build_disclosure_manifest over the document's redaction set (the spans that must not ship). Record the manifest digest.
5. Call verify_disclosure_inclusion to confirm the manifest covers exactly the redacted spans and nothing more. Record pass/fail.
6. Negative test: add one span to the manifest, re-verify, confirm the check flags it. Revert.
7. build_session_receipt over the conversion and manifest hashes; give me the ledger link.
8. Write the records note: the document id, the conversion digest, the redaction manifest digest, and the ledger link, so records management re-verifies the artifact without keeping the original machine.
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.

Make a deployment gate read a Helm run's evidence instead of a human's thumbs-up.

1. On your paired helmd, pick one completed workflow run. helmd artifact.get it; record the execution_hash and per-step digests.
2. helmd artifact.verify the run against its manifest digest. A run that fails verify must never reach the gate; confirm your policy rejects it.
3. helmd evidence.export the run as its in-toto statement export. Record the statement's subject digests.
4. Inspect the statement: confirm the subjects name the artifacts your deployment actually consumes, not a superset.
5. Negative test: modify one byte of a subject artifact and re-verify the statement; confirm verification fails. Quote the failure.
6. Wire the gate: your policy engine (cosign verify or a Kyverno verify rule against the exported statement) checks the statement before allowing the deployment. Record the policy rule text.
7. Give me the gate decision output for one allowed and one blocked deployment.
8. Write the runbook entry for the platform channel: the export command, the policy rule, the two test outputs, and the line that the gate reads digests, not opinions. 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.