[ { "id": "same-law-three-doorways", "title": "Same law, three doorways", "one_line": "Run one tool in the page, on the hosted MCP worker, and against its signed receipt, then compare the execution_hash character by character.", "doorways": [ "webmcp", "mcp", "ledger", "anchor", "zk" ], "arguments": [ { "name": "node_page", "description": "URL of the AINumbers node page to prove, e.g. https://ainumbers.co/chaingraph/art-129-webbotauth-signature-verifier.html", "required": true }, { "name": "remote_mcp_url", "description": "Hosted MCP endpoint, default https://mcp.ainumbers.co/mcp", "required": false }, { "name": "anchor_mcp_url", "description": "Anchor MCP endpoint, default https://anchor.ainumbers.co/mcp", "required": false } ], "body": "You are on an AINumbers node page. Prove that this tool gives the same answer no matter which door you use.\n\n1. List the tools this page registers via WebMCP. Note the tool name.\n2. Run that tool IN THE PAGE with the page's own synthetic sample (use the declared inputSchema; do not invent fields). Record the verdict and the execution_hash. Confirm the DevTools Network tab shows zero requests during the call.\n3. Call the SAME tool name on mcp.ainumbers.co with the identical inputs. Record its execution_hash.\n4. Call verify_execution_hash (send the artifact or its hash as claimed_hash) on the remote artifact. Then compare the two hashes character by character and state whether they are equal.\n5. Fetch this node's entry from https://ainumbers.co/chaingraph/chaingraph.json. Report compute_proof.system, receiptFormat, and journal.kernel_digest, and confirm the kernel_digest equals the sha256-source image_id in compute_images.\n6. Flip one byte in the signature field of the sample and re-run in the page. Report the new verdict and show the hash changed.\n7. Call build_session_receipt with the two matching hashes in call order. Record session_receipt_root.\n8. Call anchor_hash on anchor.ainumbers.co with session_receipt_root using the OpenTimestamps authority. Return the anchor receipt.\n9. Give me the ledger_url from the remote run, and a one-paragraph statement a regulator could read: which code ran (kernel_digest), where (three doorways), what it decided, and where the timestamp lives.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation.", "verify_surface": [ "https://ledger.ainumbers.co/", "https://ainumbers.co/chaingraph/chaingraph.json", "https://anchor.ainumbers.co/mcp" ], "group": "showcase", "requires": [ "W", "R", "A", "Z" ], "audience": "demo", "tools": [ "anchor_stamp", "build_session_receipt", "verify_execution_hash", "verify_webbotauth_signature" ] }, { "id": "signed-policy-agentic-commerce", "title": "Agent buys under a signed policy, and proves the policy governed", "one_line": "Run an agentic commerce chain under a signed Work Mandate, trip the escalation gate on purpose, and replay the gates on the ledger.", "doorways": [ "mcp", "webmcp", "ledger", "anchor" ], "arguments": [ { "name": "chain_id", "description": "Chain to run, default agent-commerce-conformance", "required": false }, { "name": "per_transaction_cap", "description": "Work Mandate per-transaction cap in EUR, default 2500", "required": false }, { "name": "breach_cart_total", "description": "Cart total that breaches the cap in the escalated run, default 3100", "required": false } ], "body": "Act as a procurement agent operating under a signed spend policy. Produce a receipt that proves the policy governed every step.\n\n1. Call find_chain with \"agent commerce conformance\" and pick the chain named agent-commerce-conformance. Call build_chaingraph on it and list each step's required policy_parameters.\n2. Draft a Work Mandate (OCG §22): principal \"treasury-ops\", agent \"procurement-bot-01\", scope limited to this chain, per-transaction cap 2,500 EUR, validity 24h from now. Call vc_issue to sign it, then show me the mandate_hash.\n3. Call run_chain on agent-commerce-conformance with escalation_transport \"resolve_handle\", passing the signed mandate and synthetic inputs where a cart total of 3,100 EUR breaches the cap. Report per-step status, the composite execution_hash, and the escalation record with its record_hash and resolve handle.\n4. Re-run with a 1,900 EUR cart. Report the composite hash and confirm no escalation.\n5. For the compliant run, call verify_execution_hash on the composite artifact, then emit_chaingraph_artifact to get the in-toto link set. Confirm each link's materials equal the previous step's products.\n6. Open the ledger_url for the compliant run. Report what the §21 gate replay shows and whether the §16 signature and mandate_hash check pass.\n7. Now prove the counterparty would accept the agent: on https://ainumbers.co/chaingraph/art-129-webbotauth-signature-verifier.html, use the page's WebMCP tool to verify a WebBotAuth-signed request header for procurement-bot-01 (synthetic sample). Record the hash.\n8. Call build_session_receipt over all hashes in order (mandate, both runs, identity check) and anchor the root with anchor_hash (FreeTSA RFC 3161). Return the session root, the anchor receipt, and a five-line summary: who authorised, what ran, where it breached, what a human still has to close out (the open resolve handle).", "verify_surface": [ "https://ledger.ainumbers.co/", "https://ainumbers.co/chaingraph/art-129-webbotauth-signature-verifier.html", "https://anchor.ainumbers.co/mcp" ], "group": "showcase", "requires": [ "R", "W", "A" ], "audience": "agentic commerce", "tools": [ "anchor_stamp", "build_chaingraph", "build_session_receipt", "emit_chaingraph_artifact", "find_chain", "run_chain", "vc_issue", "verify_execution_hash" ] }, { "id": "zero-egress-emir-proof", "title": "Regulatory proof without the data leaving the browser", "one_line": "Run four EMIR Refit validators inside the browser tab, pack and anchor only the hashes, and hand a supervisor the re-verification recipe.", "doorways": [ "webmcp", "mcp", "anchor", "ledger", "helmd" ], "arguments": [ { "name": "emir_sample_source", "description": "Page supplying the synthetic EMIR Refit auth.030 sample, default the art-158 page", "required": false }, { "name": "anchor_mcp_url", "description": "Anchor MCP endpoint, default https://anchor.ainumbers.co/mcp", "required": false } ], "body": "You are a trade-reporting agent at an EU counterparty. The trade report is confidential: it must not leave this machine. Prove readiness anyway.\n\n1. Take the synthetic EMIR Refit auth.030 sample from the art-158 page. Do NOT paste it into any remote call at any point.\n2. On each page, invoke the WebMCP-registered tool in the page with that sample:\n - art-154 check_emir_uti_completeness\n - art-155 validate_emir_upi\n - art-157 validate_emir_lifecycle_event\n - art-158 run_emir_reporting_fit\n Record each verdict and execution_hash. Confirm zero network requests during each call.\n3. Call verify_execution_hash (send the artifact or its hash as claimed_hash) on mcp.ainumbers.co for each artifact, sending ONLY the artifact (policy_parameters + output_payload as emitted by the page). State whether every recompute matches.\n4. Call build_evidence_pack with the four hashes, labelled by node, plus the four kernel_digest values from chaingraph.json.\n5. Call anchor_batch on anchor.ainumbers.co with the four hashes and the pack digest. Use two authorities: Sigstore TSA and OpenTimestamps.\n6. Build the ledger fragment link for the art-158 artifact and open it. Report the verify chips.\n7. Write the cover note for the trade repository: which checks ran, on which kernel versions, that the report content never left the workstation, and how a supervisor re-verifies with no access to us (ledger link + anchor receipt + kernel_digest).", "verify_surface": [ "https://ledger.ainumbers.co/", "https://ainumbers.co/chaingraph/art-158-emir-reporting-readiness-diagnostic.html", "https://anchor.ainumbers.co/mcp" ], "group": "showcase", "requires": [ "W", "R", "A" ], "audience": "RegTech", "tools": [ "anchor_stamp", "build_evidence_pack", "check_emir_uti_completeness", "run_emir_reporting_fit", "validate_emir_lifecycle_event", "validate_emir_upi", "verify_execution_hash" ] }, { "id": "ai-marked-asset-anchored", "title": "Is this asset real, AI-marked, and provably timestamped?", "one_line": "Validate a C2PA manifest and AI Act Art. 50 marking in the page, replay the content-credential chain remotely, and anchor the disclosure manifest to Bitcoin.", "doorways": [ "webmcp", "mcp", "anchor", "ledger" ], "arguments": [ { "name": "manifest_page", "description": "URL of the C2PA validator page, default https://ainumbers.co/chaingraph/art-123-c2pa-manifest-validator.html", "required": true }, { "name": "chain_id", "description": "Content-credential chain to replay remotely, default content-credential-verification", "required": false } ], "body": "A marketing team is about to publish an AI-generated product image with a C2PA manifest. Decide if it can ship, and give them proof.\n\n1. On https://ainumbers.co/chaingraph/art-123-c2pa-manifest-validator.html, run the WebMCP tool with the page's synthetic manifest. Record verdict + execution_hash.\n2. On art-126, run check_ai_act_art50_marking with the same manifest's assertion set. On art-127, run verify_dual_layer_disclosure. Record both hashes.\n3. Call run_chain on content-credential-verification (art-123 > art-124 > art-125) remotely with the same synthetic manifest. Compare the art-123 step hash to your in-page hash from step 1 and state whether they are identical.\n4. Call build_disclosure_manifest over the five artifacts. Then call verify_disclosure_inclusion for the art-126 artifact and show the inclusion path.\n5. Call anchor_hash with the disclosure manifest root on OpenTimestamps. Then call upgrade_ots_proof and report whether the proof is still pending or already Bitcoin-attested (pending is expected within the first hours; say so).\n6. Build the ledger link for the composite chain artifact. Open it and report the §17 kernel identity and §18 compute proof lines.\n7. Write the publish decision: ship / do not ship, the Art. 50 findings, and a verification recipe a journalist could follow without contacting us (ledger link, OTS proof, kernel digest).\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation.", "verify_surface": [ "https://ledger.ainumbers.co/", "https://ainumbers.co/chaingraph/art-123-c2pa-manifest-validator.html", "https://anchor.ainumbers.co/mcp" ], "group": "showcase", "requires": [ "W", "R", "A" ], "audience": "web3 / marketing", "tools": [ "anchor_stamp", "build_disclosure_manifest", "check_ai_act_art50_marking", "run_chain", "validate_c2pa_manifest", "verify_disclosure_inclusion", "verify_dual_layer_disclosure", "verify_timestamp_attestation" ] }, { "id": "air-gapped-helm-handover", "title": "Air-gapped control plane: the agent runs it, the human releases it, the bundle verifies without us", "one_line": "Run a CECL workflow on a loopback-only Helm daemon, hit the consent-tier boundary at evidence export, and cross-check the kernel against the public worker.", "doorways": [ "helmd", "mcp", "anchor", "ledger" ], "arguments": [ { "name": "helm_endpoint", "description": "Local Helm daemon MCP endpoint, default http://127.0.0.1:4173/mcp", "required": false }, { "name": "pack_query", "description": "catalog.search query for the pack, default cecl", "required": false } ], "body": "You are connected to a local Helm daemon at 127.0.0.1:4173. Run a CECL allowance workflow end to end, prove it, and get the evidence out the only way the daemon allows.\n\n1. Call catalog.search with \"cecl\". Pick the quarterly allowance pack. Call workflow.describe and workflow.manifest_get; list the nodes, the gates, and the manifest digest.\n2. Call workflow.dry_run on it (declare the io.modelcontextprotocol/tasks extension). Poll tasks/get until status is completed. Report the execution_hash.\n3. Call workflow.run on the same pack. Poll to completion. Report the execution_hash and whether it equals the dry run's.\n4. Call artifact.get and then artifact.verify on the real run. Report the per-step digests and the replay verdict.\n5. Attempt evidence.export with no ticket. Quote the error verbatim. Then tell me exactly what the human at the Helm UI has to do to mint a consent ticket, and wait for me to paste it.\n6. Once I paste the ticket, call evidence.export with it. Save the digest-level record.\n7. Cross-check the law: find the same kernel on mcp.ainumbers.co (find_tool \"CECL allowance\"), call it with the pack's sample inputs, and compare the kernel_digest and execution_hash to the Helm run. State whether the local daemon and the public worker agree.\n8. Call anchor_hash on the Helm run's execution_hash (Sigstore TSA). Return the receipt.\n9. Write the handover: what ran locally, what never left the machine, where the human consent sat in the flow, and how an auditor verifies the bundle offline with `helmd verify --keys ` and no network.", "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp", "https://anchor.ainumbers.co/mcp" ], "group": "showcase", "requires": [ "H", "R", "A" ], "audience": "banks / IT", "tools": [ "anchor_stamp", "find_tool", "helmd:artifact.get", "helmd:artifact.verify", "helmd:catalog.search", "helmd:evidence.export", "helmd:workflow.describe", "helmd:workflow.dry_run", "helmd:workflow.manifest_get", "helmd:workflow.run" ] }, { "id": "trust-nothing-verify-everything", "group": "persona", "doorways": [ "mcp", "webmcp", "ledger", "anchor", "zk" ], "requires": [ "R", "Z", "W", "A" ], "title": "Trust nothing, verify everything", "audience": "protocol researcher", "one_line": "Verify the estate’s own claims from primary bytes: recompute the kernel digest, check the risc0 image id, verify the Groth16 seal with an independent library, then verify a DeFi computation you ran yourself.", "tools": [ "anchor_stamp", "build_session_receipt", "classify_erc1967_proxy_slot", "compute_perp_margin", "recompute_erc4626_vault_share_math", "verify_execution_hash", "verify_merkle_airdrop_proof" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://ainumbers.co/chaingraph/art-610-erc4626-vault-share-math.html" ], "body": "Do not take this site's word for anything. Verify its claims from primary bytes, then use it for one real computation.\n\n1. Fetch https://ainumbers.co/chaingraph/chaingraph.json. Pick the node art-610 (recompute_erc4626_vault_share_math). Record compute_proof.system, receiptFormat, imageId, journal.kernel_digest.\n2. Fetch the kernel source named by the node's compute_images sha256-source entry (chaingraph/kernels/art-610-erc4626-vault-share-math.kernel.mjs). Hash it yourself. State whether it equals journal.kernel_digest. If not, stop and say so.\n3. Verify the Groth16 seal with a library you trust that is NOT ours (any BN254 Groth16 verifier). The verification key and public inputs are in the receipt; state pass/fail and which library you used.\n4. Now call recompute_erc4626_vault_share_math on mcp.ainumbers.co with a synthetic vault (totalAssets, totalSupply, a deposit). Record execution_hash. Recompute the hash yourself: RFC 8785 canonical JSON of {policy_parameters, output_payload}, SHA-256. State equality.\n5. Repeat the same inputs on the page https://ainumbers.co/chaingraph/art-610-erc4626-vault-share-math.html through its WebMCP tool. State whether the three hashes (worker, page, your recompute) are identical.\n6. Run classify_erc1967_proxy_slot and verify_merkle_airdrop_proof once each with synthetic inputs, verify each hash the same way, then build_session_receipt over all three and anchor the root with anchor_stamp on OpenTimestamps.\n7. Write the shortest possible statement of what you verified independently versus what you took on trust. Name every point where trust was still required." }, { "id": "prove-compliance-reveal-nothing", "group": "persona", "doorways": [ "mcp", "webmcp", "ledger" ], "requires": [ "R", "W" ], "title": "Prove compliance, reveal nothing", "audience": "privacy cryptographer", "one_line": "Prove a transaction passes sanctions and travel-rule predicates without disclosing the transaction.", "tools": [ "aggregate_ownership_50pct", "build_session_receipt", "generate_zk_compliance_proof", "sdjwt_issue", "sdjwt_present", "validate_canton_selective_disclosure", "validate_private_inputs", "validate_tfr_travel_rule_batch", "verify_merkle_batch", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Prove a transfer batch passes travel-rule and sanctions predicates while revealing as little as possible.\n\n1. Call validate_private_inputs to learn which fields of validate_tfr_travel_rule_batch are declared private under the §25 ocg-private-input profile. Quote the list.\n2. Build a synthetic 5-transfer batch. Call generate_zk_compliance_proof with predicate_type set to the travel-rule completeness predicate and the batch as private data; record the proof and the public statement. Confirm the public statement contains no originator or beneficiary fields.\n3. Call validate_tfr_travel_rule_batch on the same batch and confirm its verdict matches the proof's statement. Record both execution_hashes.\n4. Call aggregate_ownership_50pct on a synthetic ownership graph with one 50%-rule hit; then sdjwt_issue a credential asserting only \"sanctions_predicate: PASS\" and sdjwt_present it with every other claim withheld. Show the presentation and which claims are disclosed.\n5. Call validate_canton_selective_disclosure with a synthetic DvP where each party sees only its leg; confirm the attestation reconciles without either party's full view.\n6. Call verify_merkle_batch on the batch's audit root and one inclusion proof.\n7. build_session_receipt over every hash; give me the ledger link. Then list, precisely, what a verifier of that receipt learns about the underlying transfers (it should be: the predicates, the hashes, nothing else) and what they would need to trust.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation.\nGPU note: the generate_zk_compliance_proof 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." }, { "id": "payments-day-end-to-end", "group": "persona", "doorways": [ "mcp", "helmd", "anchor", "ledger" ], "requires": [ "R", "H", "A" ], "title": "Payments day, end to end", "audience": "payments infrastructure operator", "one_line": "One payments day: validate the pain.001, parse the camt.053, reconcile, predict fails, price CSDR penalties, seal the evidence.", "tools": [ "anchor_stamp", "build_evidence_pack", "calculate_csdr_penalty", "camt053_parse", "helmd:artifact.verify", "helmd:catalog.search", "helmd:workflow.dry_run", "model_buy_in_exposure", "pain001_validate", "predict_settlement_fail", "recon_match", "run_t1_readiness_diagnostic", "verify_address_migration_batch", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp", "https://anchor.ainumbers.co/mcp" ], "body": "Run one payments day end to end and leave evidence a regulator and an auditor can both check.\n\n1. Validate a synthetic pain.001 with pain001_validate; fix the reported defects in the input and re-run until clean. Record the hash.\n2. Parse a synthetic camt.053 with camt053_parse, then recon_match the statement lines against the pain.001 batch. Report matched / unmatched with reasons.\n3. Run verify_address_migration_batch on the beneficiary addresses to check ISO 20022 structured-address readiness.\n4. 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.\n5. Call build_evidence_pack over every hash from steps 1-4 with the kernel_digests from chaingraph.json.\n6. 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.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation.\nGPU 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." }, { "id": "verify-a-receipt-someone-sent-me", "group": "everyday", "title": "Verify a receipt someone sent me", "one_line": "I was sent a receipt link. Check it is real and see exactly what ran, without trusting the sender.", "doorways": [ "ledger", "mcp" ], "requires": [ "R", "L" ], "audience": "anyone", "tools": [ "build_session_receipt", "find_chain", "run_chain", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "You were handed a receipt link. Check it from primary sources before you rely on it.\n\n1. Open the receipt link. Copy its execution_hash and the named chain and step.\n2. Call find_chain for the chain named in the receipt; note the node and tool that produced the step.\n3. Re-run the same step yourself with run_chain using the receipt's recorded input_payload (or the tool's declared synthetic sample if inputs are not in the receipt).\n4. Call verify_execution_hash over your run's {policy_parameters, output_payload} and compare with the receipt's execution_hash, character by character.\n5. State which fields would have to change for the hash to differ, and which fields are not covered by the hash.\n6. build_session_receipt over your re-check and give me the ledger link for it.\n7. Write a three-line verdict for whoever sent you the link: reproduced / not reproduced, what matched, and the ledger link." }, { "id": "find-the-right-tool", "group": "everyday", "title": "Find the right tool", "one_line": "I need to check X. Find the tool, run the sample once, and give me a link that reproduces it.", "doorways": [ "mcp" ], "requires": [ "R" ], "audience": "first-timers", "tools": [ "build_workflow_links", "find_chain", "find_tool", "run_chain" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Find the right tool for a check you have in mind, prove it runs, and leave a reproducible link.\n\n1. State the check you want in one sentence (for example: does this reserve attestation add up).\n2. Call find_tool with that sentence. List the top three candidate tools with their one-line descriptions.\n3. Pick one candidate. Read its declared inputSchema and confirm the fields make sense for your check; if none fit, take the next candidate.\n4. Run the tool once with its synthetic sample inputs via the worker. Record the verdict and the execution_hash.\n5. Call find_chain to see whether the tool belongs to a longer chain; note the chain name if so.\n6. Call build_workflow_links for the node. Give me the deep link that re-opens the node page with the same inputs.\n7. Write a note for a colleague who has never used the site: what you wanted checked, which tool you found, the verdict, and the deep link." }, { "id": "nightly-receipt-tamper-check", "group": "everyday", "title": "Nightly receipt tamper check", "one_line": "Every night, re-verify every receipt in my export and tell me exactly what changed, if anything.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "OpenClaw / AutoClaw users", "tools": [ "build_session_receipt", "find_chain", "run_chain", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Set up the nightly habit: re-verify every receipt in your export and surface any drift.\n\n1. Export your receipts from the ledger page to receipts.json (id, chain, step, execution_hash, input_payload per line).\n2. For each receipt, call find_chain to resolve the node and tool that produced it.\n3. Re-run each step with run_chain using the recorded input_payload. Record today's execution_hash next to the stored one.\n4. Call verify_execution_hash on each pair and classify: MATCH, MISMATCH, or UNRUNNABLE (input no longer accepted).\n5. For every MISMATCH, diff the stored input_payload against today's accepted schema and quote the differing field.\n6. build_session_receipt over the whole sweep. Give me the ledger link.\n7. Write the nightly note for your own channel: counts per class, any MISMATCH with its diff, and the ledger link. Save the note where your cron already posts, so tomorrow's run compares against today's counts." }, { "id": "helm-nightly-check-with-openclaw", "group": "everyday", "title": "Helm nightly check with OpenClaw", "one_line": "Every night, recompute my extracts with helmd and post failures to my channel.", "doorways": [ "helmd" ], "requires": [ "H" ], "audience": "helm operators", "tools": [ "helmd:artifact.get", "helmd:artifact.verify", "helmd:catalog.search", "helmd:workflow.dry_run", "helmd:workflow.run" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Nightly loop for a paired helmd: recompute your packs and post only the failures.\n\n1. helmd catalog.search for each pack family you own (for example \"2052a\"); record the workflow ids and manifest digests.\n2. For each pack, helmd workflow.dry_run against today's extract files. Record any dry-run gate failures; those are your input problems, fix them before the real run.\n3. helmd workflow.run each pack for real. Poll helmd artifact.get for each run's execution_hash and per-step digests.\n4. helmd artifact.verify each run against its manifest digest. Classify: VERIFIED, FAILED, or STALE (digest drifted from yesterday).\n5. Compare each execution_hash with yesterday's note. A hash that changes when the extract did not change is your top alarm; quote the changed step.\n6. Give me the per-pack table: workflow id, digest, execution_hash, class.\n7. Write the nightly note for your channel: failures first, then the table, then the one command a teammate runs on their own helmd to reproduce any line. State plainly that nothing here required trusting your machine: every line re-verifies from the manifest digest." }, { "id": "seal-my-agent-log", "group": "everyday", "title": "Seal my agent log", "one_line": "Take my agent gateway’s action log and seal it into a bundle anyone can verify offline.", "doorways": [ "helmd", "ledger" ], "requires": [ "H" ], "audience": "agent-ops", "tools": [ "helmd:artifact.get", "helmd:artifact.verify", "helmd:catalog.search", "helmd:evidence.export", "helmd:workflow.run" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Turn a raw agent gateway action log into a sealed, offline-verifiable bundle.\n\n1. Export the gateway's action log for the window you care about (timestamp, actor, tool, input digest, output digest per line). Do not edit lines; gaps are findings, not noise.\n2. On your paired helmd, catalog.search for a pack that ingests an action log; if your deployment has one, note its workflow id. Otherwise use the generic evidence workflow.\n3. helmd workflow.run that workflow with the log as input. The run folds each line's digests into the pack's hash tree.\n4. helmd artifact.get the run: record execution_hash and the per-step digests.\n5. helmd artifact.verify the run against its manifest digest. State pass/fail and which steps are covered.\n6. helmd evidence.export the bundle. Confirm it carries: the log digests, the manifest digest, the execution_hash, and a verify command that needs no network.\n7. Give me the bundle path and a three-line handover note for your auditor: what the log covers, what the seal attests (digests, not behavior), and the exact offline command they run. Anyone with the bundle and helmd verifies it without contacting us." }, { "id": "two-hosts-one-hash", "group": "everyday", "title": "Two hosts, one hash", "one_line": "Run the same tool from two different agents and prove they agree on the execution hash.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "multi-agent teams", "tools": [ "build_session_receipt", "find_tool", "run_chain", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Prove that two independent agent hosts get byte-identical results from the same tool.\n\n1. Pick one node tool (any page in /chaingraph/ works). Call find_tool to confirm its exact mcp_name and inputSchema.\n2. Fix one synthetic input once, write it down, and do not change it for the rest of the run.\n3. Host A: run the tool through the hosted MCP worker with that input. Record execution_hash.\n4. Host B: a different agent (Claude, OpenClaw, Goose, anything that speaks MCP) runs the same tool with the same input through the same worker. Record execution_hash.\n5. Compare the two hashes character by character. If they differ, the input was not identical: diff both recorded inputs and re-run until you have either two equal hashes or a proven input difference.\n6. Call verify_execution_hash yourself over {policy_parameters, output_payload} to confirm the hash is the deterministic function both hosts should compute.\n7. build_session_receipt over the comparison and give me the ledger link.\n8. Write the note for your team's runbook: which hosts agreed, the hash, and the ledger link, so the next person repeats this with their own agents." }, { "id": "excel-to-receipt", "group": "everyday", "title": "Excel to receipt", "one_line": "My numbers live in a workbook. Evaluate it deterministically, digest the range, and give the auditor a receipt.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "finance teams", "tools": [ "build_evidence_pack", "workbook_csv_parse", "workbook_evaluate", "workbook_range_digest", "workbook_roundtrip_verify" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Take a spreadsheet out of email-and-trust and put it under a receipt.\n\n1. Export one workbook sheet to CSV. Use a synthetic copy if the sheet has real counterparty data.\n2. Call workbook_csv_parse. Record the parsed shape (rows, columns, types) and any cell that failed to parse.\n3. Call workbook_evaluate over the formula range. Record the computed values and the evaluation order the engine used.\n4. Call workbook_range_digest over the evaluated range. Record the digest; this is what the auditor will re-verify.\n5. Call workbook_roundtrip_verify to prove the evaluated workbook round-trips to the same digest. State pass/fail.\n6. build_evidence_pack over the parse, evaluate, and digest hashes.\n7. Give me the ledger link for the pack and the one command an auditor runs to recompute the digest from the same CSV.\n8. Write the note for your finance lead: which range is under receipt, the digest, and what the receipt does and does not claim (it covers the numbers as given, not the business judgment behind them)." }, { "id": "contract-redline-proof", "group": "everyday", "title": "Contract redline proof", "one_line": "Show exactly what changed between two contract versions and seal the diff.", "doorways": [ "mcp", "anchor" ], "requires": [ "R", "A" ], "audience": "legal ops", "tools": [ "anchor_stamp", "build_session_receipt", "redline_diff", "redline_verify" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Make a contract diff that outlives both parties' copy of the file.\n\n1. Export both contract versions to plain text (v1.txt, v2.txt). Use synthetic or redacted text if the contract is confidential; the proof covers structure, not secrets.\n2. Call redline_diff on the two files. Record the changed spans with their context.\n3. Call redline_verify to confirm the diff is complete and reproduces both documents from v1 plus the patch. State pass/fail.\n4. Confirm the patch alone, applied to v1, yields v2 byte-for-byte; quote the byte counts of v1, patch, and v2.\n5. anchor_stamp the patch digest on OpenTimestamps. Record the OTS receipt.\n6. build_session_receipt over the diff and verify hashes; give me the ledger link.\n7. Write the note for the deal file: the two version identifiers, the patch digest, the OTS receipt, and the one command that re-applies the patch and re-verifies the digest years from now, without contacting us." }, { "id": "is-this-counterparty-real", "group": "everyday", "title": "Is this counterparty real?", "one_line": "Check the LEI, its relationships, and the GLEIF snapshot digest before you onboard them.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "onboarding", "tools": [ "acdc_said_check", "build_session_receipt", "check_lei_relationship_consistency", "digest_gleif_snapshot", "lei_kyb_check" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Onboarding check for one counterparty, with every claim re-verifiable.\n\n1. Get the counterparty's LEI from their paperwork. Do not accept a name alone.\n2. Call lei_kyb_check on the LEI. Record the registered status, entity type, and any exceptions.\n3. Call check_lei_relationship_consistency to pull the relationship tree (parents, children). Flag any relationship your onboarding form does not mention.\n4. Call digest_gleif_snapshot on the GLEIF snapshot file covering today. Record the snapshot digest; this is the public dataset your conclusions rest on.\n5. If the counterparty presented a SAID, call acdc_said_check on it and record whether it resolves.\n6. Give me the ledger link for the session receipt covering all four checks (build_session_receipt if your client does not build it automatically).\n7. Write the onboarding note for the KYC reviewer: what was checked, against which snapshot digest, what matched, what needs a human call, and the ledger link.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "is-my-agent-payments-ready", "group": "commerce", "title": "Is my agent payments-ready?", "one_line": "Grade my stack for agentic payments and MCP, then fix the top gap and re-grade.", "doorways": [ "mcp", "webmcp", "ledger" ], "requires": [ "R" ], "audience": "CTOs", "tools": [ "build_session_receipt", "lint_mcp_server_conformance", "run_agentic_readiness_diagnostic", "score_mcp_server_readiness" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Grade your agentic-payments and MCP surface, fix the worst gap, prove the fix.\n\n1. Call run_agentic_readiness_diagnostic against your deployment's public URL. Record the overall grade and the ranked gap list.\n2. Call score_mcp_server_readiness on your MCP endpoint. Record the score and the failing dimensions.\n3. Call lint_mcp_server_conformance on the same endpoint. Record every conformance violation with its rule id.\n4. Pick the single highest-impact gap across the three reports. State what fixing it requires and who owns it.\n5. Fix that one thing (or have the owner fix it). Change nothing else.\n6. Re-run all three tools. Quote the before/after numbers for the one gap; leave the others untouched.\n7. Give me the ledger link for the re-run session (build_session_receipt over the two diagnostic runs).\n8. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "ap2-cart-to-payment-chain", "group": "commerce", "title": "AP2 cart to payment chain", "one_line": "Build an AP2 mandate, validate it, hash-chain the cart, and correlate it with an x402 settlement.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "agentic payments", "tools": [ "build_ap2_cartmandate_hashchain", "build_session_receipt", "correlate_ap2_cartmandate_x402", "draft_ap2_mandate_credential", "simulate_x402_flow", "validate_ap2_mandate_chain", "validate_ap2_mandate_credential" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Walk one synthetic purchase through the full AP2 evidence chain.\n\n1. Call draft_ap2_mandate_credential for a synthetic cart (two line items, a spend cap, an expiry). Record the credential id.\n2. Call validate_ap2_mandate_credential on the draft. Confirm the signature structure and the cap/expiry fields; record pass/fail.\n3. Tamper-test: change one line item's price in the signed cart, re-validate, and confirm the validator rejects it. Revert.\n4. Call build_ap2_cartmandate_hashchain over the cart events. Record the chain root.\n5. Call validate_ap2_mandate_chain on the chain. Record pass/fail and which links are covered.\n6. Call simulate_x402_flow for the settlement, then correlate_ap2_cartmandate_x402 to bind the settlement to the mandate chain. Record the correlation verdict.\n7. build_session_receipt over every hash; give me the ledger link.\n8. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "agent-identity-gate", "group": "commerce", "title": "Agent identity gate", "one_line": "Verify a bot’s RFC 9421 signature, replay window, and pinned JWKS before letting it in.", "doorways": [ "webmcp", "mcp", "ledger" ], "requires": [ "W", "R" ], "audience": "platform security", "tools": [ "check_jwks_pinned_directory", "check_webbotauth_nonce_replay", "run_chain", "verify_webbotauth_signature" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Decide whether an automated client may enter, and keep the decision receipt.\n\n1. Capture the client's request signature headers (RFC 9421 signature-input, signature, and the webbotauth document).\n2. Call verify_webbotauth_signature on the captured headers and the served webbotauth document. Record pass/fail and the key id used.\n3. Call check_webbotauth_nonce_replay with the nonce and timestamp window. Record whether the nonce was seen before.\n4. Call check_jwks_pinned_directory to confirm the signing key is the key the operator pinned in the directory. Record the pin match.\n5. Run the chain visa-tap-agent-verification with run_chain, which composes the three checks. Record the chain verdict and execution_hash.\n6. Negative test: replay step 2 with a one-byte-changed signature and confirm it fails. Quote the error.\n7. Give me the ledger link for the chain receipt.\n8. 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).\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "agent-spend-policy-stress", "group": "commerce", "title": "Agent spend policy stress", "one_line": "Stress my agent’s spend policy against 10,000 synthetic transactions and export the Policy Mandate.", "doorways": [ "webmcp", "mcp", "ledger" ], "requires": [ "W", "R", "Z" ], "audience": "treasury", "tools": [ "build_session_receipt", "simulate_agent_spend_policy", "simulate_spend_policy", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Find out what your agent's spend policy actually does before a live agent finds out for you.\n\n1. Write down the policy as you believe it is (per-transaction cap, daily cap, merchant allowlist). This is the claim you are testing.\n2. 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.\n3. 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.\n4. Find the worst class: the transactions where the outcome contradicts your step-1 claim. Quote three examples with inputs.\n5. Adjust the policy (or file the fix), re-run only the failing class, and quote the new counts.\n6. Export the effective Policy Mandate your simulation ran under; record its digest.\n7. build_session_receipt over the runs; give me the ledger link.\n8. Write the note for treasury: what the policy really enforces, the three example transactions, the mandate digest, and the ledger link.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation.\nGPU 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." }, { "id": "authz-decision-receipt", "group": "commerce", "title": "AuthZ decision receipt", "one_line": "Make an AuthZEN decision, then prove the gate decision in the receipt.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "IAM", "tools": [ "build_session_receipt", "checklist_step_receipt", "checklist_validate_definition", "compute_authzen_conformance_fixture" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Prove that the access decision your gate claims is the decision it made.\n\n1. Call compute_authzen_conformance_fixture for one AuthZEN evaluation request (subject, action, resource). Record the expected decision.\n2. Send the same request to your gate. Record what it actually decided. If expected and actual differ, that difference is the whole finding.\n3. Call checklist_validate_definition on the checklist that defines this decision step. Record pass/fail and the definition digest.\n4. Call checklist_step_receipt for the step: this binds the decision, the definition digest, and the inputs into one receipt. Record execution_hash.\n5. Negative test: change the resource id in the request, re-run the step, confirm the receipt's hash changes. Quote both hashes.\n6. build_session_receipt over the fixture, the definition check, and both step receipts. Give me the ledger link.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "stablecoin-reserve-proof", "group": "crypto", "title": "Stablecoin reserve proof", "one_line": "Pre-check a GENIUS Act reserve attestation, stress it under MiCA, and verify the reserve proof chain.", "doorways": [ "mcp", "ledger", "anchor" ], "requires": [ "R", "A" ], "audience": "issuers", "tools": [ "anchor_stamp", "calculate_mica_own_funds", "precheck_reserve_attestation", "run_chain", "simulate_stablecoin_reserve", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Take one reserve attestation from PDF-trust to proof chain.\n\n1. Call precheck_reserve_attestation on a synthetic GENIUS-style attestation (reserve assets, liabilities, custodian lines). Record every flagged field.\n2. Call simulate_stablecoin_reserve with a redemption scenario (10% and 30% same-day redemption). Record the survival verdict per scenario.\n3. Call calculate_mica_own_funds for the same balance sheet under the MiCA own-funds classes. Record the required amount.\n4. Run the chain reserve-proof-verification with run_chain, which composes the checks into one verdict. Record execution_hash.\n5. Break-test: inflate one reserve line by 1 unit, re-run the chain, confirm the verdict changes. Revert.\n6. anchor_stamp the passing chain's execution_hash on OpenTimestamps.\n7. Give me the ledger link for the chain receipt and the OTS receipt.\n8. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation.\nGPU 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." }, { "id": "travel-rule-batch-with-merkle-audit", "group": "crypto", "title": "Travel-rule batch with Merkle audit", "one_line": "Validate a transfer batch under TFR, then verify its Merkle audit batch.", "doorways": [ "webmcp", "mcp", "ledger" ], "requires": [ "W", "R" ], "audience": "VASPs", "tools": [ "build_session_receipt", "run_chain", "validate_tfr_travel_rule_batch", "verify_merkle_batch" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Prove a travel-rule batch and leave an audit path that does not depend on your systems.\n\n1. Build a synthetic batch of 20 transfers with complete originator/beneficiary fields and 3 deliberately defective ones.\n2. Call validate_tfr_travel_rule_batch. Record per-transfer verdicts; confirm exactly the 3 defectives fail and quote their defect codes.\n3. Call verify_merkle_batch on the batch's audit root with one inclusion proof per defective transfer. Confirm each proof resolves to the root.\n4. Negative test: swap two transfers in the batch, re-verify the inclusion proofs, confirm they fail against the same root. Revert.\n5. Run the chain mica-travel-rule with run_chain for the composed regulatory verdict. Record execution_hash.\n6. build_session_receipt over the batch validation and Merkle checks; give me the ledger link.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "perp-liquidation-what-if", "group": "crypto", "title": "Perp liquidation what-if", "one_line": "Find where my perp gets liquidated across venues and see the full lifecycle scenario.", "doorways": [ "mcp", "ledger" ], "requires": [ "R", "Z" ], "audience": "DeFi traders", "tools": [ "build_session_receipt", "compute_perp_margin", "model_perp_position", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Know your liquidation point from a deterministic model, not a dashboard screenshot.\n\n1. Write down the position: notional, entry, leverage, funding, margin. Synthetic numbers only.\n2. Call compute_perp_margin for the current state. Record the margin ratio and the maintenance threshold.\n3. 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.\n4. Re-run the worst rung with funding doubled. Note how much the liquidation price moves; that sensitivity is your model risk.\n5. 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.\n6. build_session_receipt over the ladder runs; give me the ledger link.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "cross-chain-transfer-check", "group": "crypto", "title": "Cross-chain transfer check", "one_line": "Validate a CCTP v2 transfer and classify L2 finality before you rely on it.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "bridges / treasuries", "tools": [ "build_session_receipt", "check_linea_l2_finality_window", "run_chain", "validate_cctp_v2_transfer" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Check a bridged transfer before you treat it as settled.\n\n1. Take the synthetic CCTP v2 message attestation for the transfer (nonce, amount, source/destination domain).\n2. Call validate_cctp_v2_transfer. Record the attestation verdict and the mint/destroy pair it implies.\n3. 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.\n4. Run the chain arc-dvp-settlement with run_chain to place the transfer in a settlement context. Record execution_hash.\n5. 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.\n6. build_session_receipt over the checks; give me the ledger link.\n7. Write the treasury note: transfer id, attestation verdict, finality status, the exposure window in minutes, and the ledger link.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "token-standards-audit", "group": "crypto", "title": "Token standards audit", "one_line": "Audit an ERC-4626 vault’s share math, an ERC-1967 proxy slot, an ERC-2981 royalty, and an airdrop proof in one pass.", "doorways": [ "mcp", "ledger", "anchor" ], "requires": [ "R", "Z", "A" ], "audience": "protocol devs", "tools": [ "anchor_stamp", "build_session_receipt", "calculate_erc2981_royalty", "classify_erc1967_proxy_slot", "recompute_erc4626_vault_share_math", "verify_merkle_airdrop_proof" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "One pass over four token-standard claims, each under its own receipt.\n\n1. 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.\n2. 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.\n3. Call calculate_erc2981_royalty for a synthetic sale. Record the royalty and the receiver; confirm rounding matches the standard's expectation.\n4. Call verify_merkle_airdrop_proof for one claimed airdrop allocation against a synthetic root. Record pass/fail and the proof path.\n5. 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.\n6. build_session_receipt over all four checks; anchor the root with anchor_stamp.\n7. Give me the ledger link and the OTS receipt.\n8. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "casp-authorization-path", "group": "crypto", "title": "CASP authorization path", "one_line": "Am I a MiCA CASP, what own funds do I need, and is my surveillance MAR-ready?", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "crypto firms", "tools": [ "assess_mar_crypto_surveillance", "assess_mica_casp_readiness", "build_session_receipt", "calculate_mica_own_funds", "run_mica_casp_fit" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Scope your MiCA CASP posture with each answer under a receipt.\n\n1. Call run_mica_casp_fit with your synthetic service inventory (which crypto-asset services you render, to whom). Record the fit verdict per service.\n2. Call assess_mica_casp_readiness for the authorization gap list. Record each gap with its class.\n3. Call calculate_mica_own_funds on the synthetic balance sheet. Record the computed own-funds requirement and which of the three bases binds.\n4. Call assess_mar_crypto_surveillance on a synthetic order/transaction sample. Record the coverage verdict and the flagged patterns.\n5. Pick the one gap that blocks authorization first; state the evidence the reviewer will ask for.\n6. build_session_receipt over the four runs; give me the ledger link.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "tokenized-treasury-dvp", "group": "crypto", "title": "Tokenized treasury DvP", "one_line": "Validate a DTC-custodied tokenized treasury issuance and its Canton selective-disclosure DvP.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "capital markets", "tools": [ "build_session_receipt", "run_chain", "validate_canton_selective_disclosure", "validate_dtc_tokenized_treasury" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Check a tokenized treasury trade where each party is supposed to see only its leg.\n\n1. Call validate_dtc_tokenized_treasury on a synthetic DTC-custodied issuance (CUSIP, par, coupon, token wrapper). Record the structural verdict and any flagged field.\n2. Build the synthetic DvP: two parties, each with a leg, payment-versus-payment.\n3. Call validate_canton_selective_disclosure. Confirm party A's attestation reconciles while exposing only A's leg, and the same for B.\n4. Privacy test: attempt to read the counterparty leg from A's view; confirm the tool returns nothing. Quote the returned shape.\n5. Run the chain wholesale-settlement-cross-network-dvp with run_chain. Record the composed verdict and execution_hash.\n6. build_session_receipt over the two validations and the chain; give me the ledger link.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "liquidity-stress-morning", "group": "banking", "title": "Liquidity stress morning", "one_line": "Run LCR/NSFR stress, then Basel RWA scenarios, then VaR, and bind it all in one session receipt.", "doorways": [ "mcp", "ledger" ], "requires": [ "R", "Z" ], "audience": "treasury / risk", "tools": [ "build_session_receipt", "compute_portfolio_var", "compute_rwa_scenarios", "compute_stress_test_scenarios", "run_liquidity_stress_test", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "One morning risk run, every number re-verifiable.\n\n1. 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.\n2. Call compute_stress_test_scenarios for the scenario set. Record which scenario is worst and by how much.\n3. Call compute_rwa_scenarios across the Basel RWA approaches for the same book. Record the RWA range and the approach that binds.\n4. Call compute_portfolio_var for the trading book at 99/1-day, then under the worst stress path. Record both numbers.\n5. Consistency check: state in one sentence whether the VaR book and the RWA book overlap, and where the models disagree.\n6. build_session_receipt over the four runs. Give me the ledger link.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation.\nGPU 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." }, { "id": "frtb-pre-validate", "group": "banking", "title": "FRTB pre-validate", "one_line": "Pre-validate my FRTB IMA expected shortfall before the regulator does.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "market risk", "tools": [ "build_session_receipt", "run_chain", "simulate_frtb_es" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Run the desk's FRTB expected shortfall through the same arithmetic a reviewer would.\n\n1. Assemble a synthetic trading-position sample for one desk (instruments, sensitivities, liquidity horizons).\n2. Call simulate_frtb_es under the IMA expected-shortfall settings. Record the ES figure and the liquidity-horizon mapping used.\n3. Run the chain basel-endgame-frtb-capital with run_chain for the capital composition. Record execution_hash.\n4. Cross-check: recompute ES at doubled liquidity horizons and quote the delta; this is where most desk models are thin.\n5. Record which inputs drove the result: perturb the largest position 10 percent and quote the ES delta.\n6. build_session_receipt over the runs; give me the ledger link.\n7. Write the pre-validation note for the model-risk team: the ES figure, the horizon sensitivity, the perturbation delta, and the ledger link.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "cecl-quarter-close", "group": "banking", "title": "CECL quarter close", "one_line": "Close the CECL quarter locally with helmd and prove the allowance rollforward.", "doorways": [ "helmd", "mcp", "ledger" ], "requires": [ "H", "R" ], "audience": "finance", "tools": [ "build_session_receipt", "find_tool", "helmd:artifact.get", "helmd:artifact.verify", "helmd:catalog.search", "helmd:workflow.dry_run", "helmd:workflow.run" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Close the quarter's CECL allowance where the numbers never leave your machine.\n\n1. helmd catalog.search for the CECL allowance pack; record the workflow id and manifest digest.\n2. helmd workflow.dry_run the pack against this quarter's synthetic loan tape. Fix any gate failure before the real run.\n3. helmd workflow.run the pack. Poll helmd artifact.get for the execution_hash and per-step digests.\n4. helmd artifact.verify the run against the manifest digest. State pass/fail.\n5. 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.\n6. build_session_receipt over the local run and the remote cross-check; give me the ledger link.\n7. Write the close note for the controller: the allowance figure, the manifest digest it came from, the cross-check result, and the ledger link." }, { "id": "consumer-loan-compliance", "group": "banking", "title": "Consumer loan compliance", "one_line": "Does this loan pass QM points-and-fees, HPML escrow, Reg Z thresholds and MLA coverage?", "doorways": [ "webmcp", "mcp", "ledger" ], "requires": [ "W", "R" ], "audience": "lenders", "tools": [ "build_session_receipt", "check_qm_points_and_fees", "classify_mla_charge_inclusion", "compute_deterministic_amortization_schedule", "lookup_reg_z_thresholds", "test_hpml_escrow" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Run one synthetic loan through the four consumer checks and bind the results.\n\n1. Write the loan facts once (amount, rate, points, fees, lien status, borrower type). Synthetic data only.\n2. Call lookup_reg_z_thresholds for the current applicable thresholds. Record them; everything downstream cites these.\n3. Call check_qm_points_and_fees. Record pass/fail with the points-and-fees computation shown.\n4. Call test_hpml_escrow. Record whether the escrow requirement attaches and why.\n5. Call classify_mla_charge_inclusion over the fee list. Record which charges count as MLA fees and the final coverage verdict.\n6. Call compute_deterministic_amortization_schedule. Record the APR-consistent schedule digest.\n7. Boundary test: move the loan amount 1 dollar past a threshold from step 2 and confirm the affected verdicts flip. Revert.\n8. build_session_receipt over the five checks; give me the ledger link.\n9. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "credit-model-ai-act", "group": "banking", "title": "Credit model AI Act pack", "one_line": "Score credit default risk and produce the EU AI Act conformity pack for the model.", "doorways": [ "mcp", "ledger" ], "requires": [ "R", "Z" ], "audience": "model risk", "tools": [ "assess_ai_act_conformity", "build_session_receipt", "run_chain", "score_credit_default_risk", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Put the credit model's governance evidence where an examiner can recompute it.\n\n1. Call score_credit_default_risk on a synthetic applicant pool. Record the score distribution and the top features the model used.\n2. 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).\n3. Run the chain ai-governance-credit-ai-conformity with run_chain. Record the composed verdict and execution_hash.\n4. Gap list: name the conformity items with no evidence yet and who owns each.\n5. build_session_receipt over the scoring run, the conformity assessment, and the chain; give me the ledger link.\n6. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation.\nGPU 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." }, { "id": "fr2052a-daily", "group": "banking", "title": "FR 2052a daily", "one_line": "Classify today’s FR 2052a extract locally and seal it.", "doorways": [ "helmd" ], "requires": [ "H" ], "audience": "US banks", "tools": [ "helmd:artifact.get", "helmd:artifact.verify", "helmd:catalog.search", "helmd:evidence.export", "helmd:workflow.dry_run", "helmd:workflow.run" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "The daily 2052a classification, sealed before you send anything anywhere.\n\n1. helmd catalog.search \"2052a\". Record the classify pack's workflow id and manifest digest.\n2. helmd workflow.dry_run against today's synthetic extract. Fix gate failures; do not classify a file the gates reject.\n3. helmd workflow.run. Poll helmd artifact.get for the execution_hash and per-line classification digests.\n4. helmd artifact.verify against the manifest digest. State pass/fail.\n5. Spot-check three classifications by hand against the instruction text; record agreement.\n6. helmd evidence.export the day's bundle. Confirm it carries the manifest digest, the execution_hash, and the offline verify command.\n7. Give me the bundle path and the ledger link if your deployment mirrors runs.\n8. 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." }, { "id": "sanctions-programme-fit", "group": "compliance", "title": "Sanctions programme fit", "one_line": "Scope my sanctions programme, aggregate 50% ownership, check list coverage, calibrate fuzzy matching.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "compliance", "tools": [ "aggregate_ownership_50pct", "build_session_receipt", "classify_eccn_dual_use", "run_chain", "run_sanctions_screening_fit" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Test the sanctions programme's mechanics against cases you control.\n\n1. Call run_sanctions_screening_fit with your synthetic screening configuration and sample flow. Record the coverage verdict per list.\n2. 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.\n3. 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.\n4. Call classify_eccn_dual_use on one synthetic item to confirm the export-control lane is wired. Record the classification.\n5. Run the chain sanctions-screening-demo (or the sanctions chain your inventory names) with run_chain. Record execution_hash.\n6. build_session_receipt over the runs; give me the ledger link.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "dora-incident-in-four-hours", "group": "compliance", "title": "DORA incident in four hours", "one_line": "Classify this incident under DORA, simulate the ICT cascade, produce the escalation record.", "doorways": [ "mcp", "ledger", "anchor" ], "requires": [ "R", "A" ], "audience": "ops resilience", "tools": [ "anchor_stamp", "build_session_receipt", "classify_dora_incident", "run_chain", "simulate_ict_cascade", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "The first four hours of a DORA incident, with every classification step receipted.\n\n1. Write the incident facts as known at hour zero (system, impact, detection time). Facts only; no cause speculation.\n2. Call classify_dora_incident. Record the classification and the reporting clocks it starts, with their deadlines.\n3. Call simulate_ict_cascade from the affected service. Record the downstream services hit and the order they fall over.\n4. Run the chain dora-escalation-demo with run_chain for the composed escalation verdict. Record execution_hash.\n5. 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.\n6. build_session_receipt over the classification and cascade; anchor the receipt root with anchor_stamp.\n7. Give me the ledger link and the OTS receipt.\n8. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation.\nGPU 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." }, { "id": "aml-typology-triage", "group": "compliance", "title": "AML typology triage", "one_line": "Score transactions for AML typologies and anomalies, then seal the triage.", "doorways": [ "mcp", "ledger" ], "requires": [ "R", "Z" ], "audience": "FIU / AML", "tools": [ "build_evidence_pack", "detect_transaction_anomalies", "score_aml_typologies", "simulate_app_fraud_graph", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Triage a synthetic alert batch and seal the reasoning trail.\n\n1. Build a synthetic batch of 50 transactions embedding three known typologies (structuring, rapid movement, round-amount pairing).\n2. Call score_aml_typologies. Record the typology scores; confirm the three planted typologies outrank the filler.\n3. Call detect_transaction_anomalies. Record the anomaly list and the method each was flagged by.\n4. Call simulate_app_fraud_graph over the customer-payment graph. Record the fraud clusters found and their centrality scores.\n5. Disagreement check: name the transactions the typology scorer and the anomaly detector disagree on; those are your review queue, not noise.\n6. build_evidence_pack over the scores, anomalies, and graph digests. Give me the ledger link for the pack.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation.\nGPU 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." }, { "id": "pqc-migration-plan", "group": "compliance", "title": "PQC migration plan", "one_line": "Find where I am exposed to harvest-now-decrypt-later and get the migration plan.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "CISOs", "tools": [ "build_session_receipt", "classify_blockchain_quantum_risk", "plan_tls_pki_migration", "run_pqc_timeline_fit" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Turn post-quantum anxiety into a dated, receipted plan.\n\n1. 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.\n2. Call plan_tls_pki_migration for the TLS/PKI estate. Record the migration order, the hybrid periods, and the cutover dates.\n3. 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.\n4. Name the data with the longest secrecy requirement; that is what HNDL actually threatens. Quote its decrypt-by horizon versus the migration date.\n5. build_session_receipt over the three runs; give me the ledger link.\n6. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "cbam-import-liability", "group": "compliance", "title": "CBAM import liability", "one_line": "Resolve CBAM default values, aggregate precursors, and price certificates for this import schedule.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "importers / ESG", "tools": [ "aggregate_cbam_precursor_emissions", "build_session_receipt", "calculate_cbam_embedded_emissions", "model_cbam_certificate_cost", "resolve_cbam_default_value", "score_taxonomy_alignment" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Price one import schedule's CBAM exposure with every number re-computable.\n\n1. List the synthetic import schedule: goods, CN codes, origin, quantities, per quarter.\n2. Call resolve_cbam_default_value per good. Record the default embedded-emissions values used where no actuals exist.\n3. Call aggregate_cbam_precursor_emissions for goods with precursor inputs. Record the aggregated values.\n4. Call calculate_cbam_embedded_emissions per line. Record the totals.\n5. Call model_cbam_certificate_cost across the schedule with this quarter's certificate price and the free-allocation phase-down. Record the cost range.\n6. Call score_taxonomy_alignment for the optional alignment KPI. Record the score.\n7. build_session_receipt over the runs; give me the ledger link.\n8. 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).\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "supply-chain-provenance", "group": "compliance", "title": "Supply chain provenance", "one_line": "Verify the DSCSA T3, the FSMA 204 CTEs, and the DPP carrier for this product.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "pharma / food / consumer goods", "tools": [ "build_session_receipt", "resolve_recall_trace", "validate_dpp_data_carrier", "validate_fsma204_cte", "verify_dscsa_transaction_statement" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Provenance for one product across three regimes, one receipt.\n\n1. Call verify_dscsa_transaction_statement on the synthetic T3 data for the pharma line. Record pass/fail and the trading-party identifiers.\n2. 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.\n3. Call resolve_recall_trace for both lines: given a synthetic lot, record the trace-up and trace-down paths and their terminals.\n4. Call validate_dpp_data_carrier on the digital product passport carrier. Record whether the carrier resolves and what data it serves.\n5. 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.\n6. build_session_receipt over the four checks; give me the ledger link.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "certified-payroll-recompute", "group": "compliance", "title": "Certified payroll recompute", "one_line": "Recompute certified payroll against prevailing wage and sign the receipt.", "doorways": [ "webmcp", "mcp", "ledger" ], "requires": [ "W", "R" ], "audience": "contractors", "tools": [ "build_session_receipt", "recompute_certified_payroll_pwa", "verify_execution_hash" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Recompute a certified payroll from the raw timesheets so the certification has a hash behind it.\n\n1. Prepare a synthetic weekly payroll: workers, classifications, hours per day, fringe payments.\n2. 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.\n3. Confirm the recomputation matches what was certified for the week; quote any line that differs with both numbers.\n4. Call verify_execution_hash (send the artifact or its hash as claimed_hash) over the recompute output. Record the hash.\n5. Negative test: change one worker's hours by one, re-run, confirm both the totals and the hash change. Revert.\n6. build_session_receipt over the runs; give me the ledger link.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "mcp-server-self-attest", "group": "compliance", "title": "MCP server self-attest", "one_line": "Lint my MCP server, score readiness, and produce the self-attestation pack.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "MCP builders", "tools": [ "build_session_receipt", "lint_mcp_server_conformance", "score_mcp_server_readiness" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Self-attest your MCP server with receipts instead of a checkbox.\n\n1. Call lint_mcp_server_conformance against your server endpoint. Record every violation with its rule id and severity.\n2. Call score_mcp_server_readiness. Record the score, the per-dimension breakdown, and the weakest dimension.\n3. Fix the conformance violations (or file them with owners). Fix nothing else this pass.\n4. Re-run both tools. Quote before/after per dimension; the score delta is your attestation claim.\n5. Rescan after one week without changes to confirm the score holds; that re-run is what makes it an attestation rather than a snapshot.\n6. build_session_receipt over all four runs; give me the ledger link.\n7. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "agent-audit-trail-for-the-examiner", "group": "governance", "title": "Agent audit trail for the examiner", "one_line": "Aggregate every receipt from today’s agent session into one audit object a regulator can re-verify.", "doorways": [ "mcp", "ledger", "anchor" ], "requires": [ "R", "A" ], "audience": "audit / AI Act Art. 12", "tools": [ "aggregate_execution_receipts", "anchor_stamp", "build_session_receipt", "compose_ap2_prompt" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "One audit object for a day of agent activity, framed the way an examiner asks.\n\n1. Collect today's execution receipts (ids and hashes) from your agent sessions. Synthetic sessions are fine; the mechanics are what you are proving.\n2. Call aggregate_execution_receipts over the set. Record the aggregate digest and any receipt it could not include, with the reason.\n3. Call build_session_receipt over the aggregate. This is the Art. 12-style log entry: what ran, when, under which hash.\n4. Call compose_ap2_prompt to render the regulator-framed summary of the aggregate. Record the prompt text it returns.\n5. 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.\n6. anchor_stamp the aggregate digest on OpenTimestamps.\n7. Give me the ledger link and the OTS receipt.\n8. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "document-to-receipt", "group": "governance", "title": "Document to receipt", "one_line": "Convert this document deterministically, prove the sanitisation, and emit the digest manifest.", "doorways": [ "mcp", "ledger" ], "requires": [ "R" ], "audience": "records", "tools": [ "build_disclosure_manifest", "build_session_receipt", "convert_markdown_document", "verify_disclosure_inclusion" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Move a document from someone's laptop trust into a verifiable record.\n\n1. Take one markdown document and its converted form (the published artifact). Synthetic or public text only.\n2. Call convert_markdown_document on the source. Record the conversion digest and whether the conversion is deterministic (re-run and compare).\n3. Diff the fresh conversion against the published artifact. If they differ, the published copy drifted; quote the differing lines.\n4. Call build_disclosure_manifest over the document's redaction set (the spans that must not ship). Record the manifest digest.\n5. Call verify_disclosure_inclusion to confirm the manifest covers exactly the redacted spans and nothing more. Record pass/fail.\n6. Negative test: add one span to the manifest, re-verify, confirm the check flags it. Revert.\n7. build_session_receipt over the conversion and manifest hashes; give me the ledger link.\n8. 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.\nCall shape: every ChainGraph node tool takes its arguments nested under one wrapper object, e.g. {\"policy_parameters\": { ... }}; flat arguments are discarded by schema validation." }, { "id": "helm-bundle-to-policy-engine", "group": "governance", "title": "Helm bundle to policy engine", "one_line": "Export a Helm run as an in-toto statement and gate a deployment on it.", "doorways": [ "helmd" ], "requires": [ "H" ], "audience": "platform teams", "tools": [ "helmd:artifact.get", "helmd:artifact.verify", "helmd:evidence.export" ], "arguments": [], "verify_surface": [ "https://ledger.ainumbers.co/", "https://mcp.ainumbers.co/mcp" ], "body": "Make a deployment gate read a Helm run's evidence instead of a human's thumbs-up.\n\n1. On your paired helmd, pick one completed workflow run. helmd artifact.get it; record the execution_hash and per-step digests.\n2. helmd artifact.verify the run against its manifest digest. A run that fails verify must never reach the gate; confirm your policy rejects it.\n3. helmd evidence.export the run as its in-toto statement export. Record the statement's subject digests.\n4. Inspect the statement: confirm the subjects name the artifacts your deployment actually consumes, not a superset.\n5. Negative test: modify one byte of a subject artifact and re-verify the statement; confirm verification fails. Quote the failure.\n6. 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.\n7. Give me the gate decision output for one allowed and one blocked deployment.\n8. 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." } ]