A sample nobody could steer, tested by arithmetic anyone can replay. The item manifest is hashed and committed while the beacon pulse that will seed the draw does not yet exist; the pulse then drives a deterministic HMAC-DRBG walk over the manifest; the drawn population is recomputed by the node configured for the regime under test. One generic chain covers both directions of that last stage: certified-payroll prevailing wage as the first instance, multi-garnishment stacking as a second configuration. Regime instances are configurations of these steps. They are not new nodes, and adding one does not change the ceremony.
Every part of this is ordinary hashing. What makes the result hard to argue with is the sequence in which the two commitments happen, and each step of that sequence leaves its own artifact.
derive_beacon_fair_sample{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "derive_beacon_fair_sample",
"arguments": {
"beacon_source": "drand_quicknet",
"beacon_round": "4321000",
"beacon_randomness": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b85",
"item_manifest_hash": "sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
"item_count": 250,
"sample_size": 10,
"algorithm_id": "hmac-drbg-sha256-v1"
}
},
"id": 1
}
recompute_certified_payroll_pwa{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "recompute_certified_payroll_pwa",
"arguments": {
"project_ref": "SYNTH-PROJ-574-A",
"week_ending_label": "2026-08-01 payroll week",
"currency": "USD",
"pwa_mode": true,
"wage_determination": [
{"classification": "Electrician", "base_rate_minor_units": 4200, "fringe_rate_minor_units": 1100}
],
"payroll_rows": [
{"worker_id": "W-1", "classification": "Electrician", "st_hours": 40, "ot_hours": 4,
"rate_paid_minor_units": 4200, "fringe_paid_minor_units": 1100}
],
"submitted_payroll": [{"worker_id": "W-1", "gross_minor_units": 241600}]
}
},
"id": 2
}
recompute_garnishment_stack{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "recompute_garnishment_stack",
"arguments": {
"employee_ref": "SYNTH-EMP-001",
"period_label": "2026-01-15 biweekly pay period",
"currency": "USD",
"gross_minor_units": 100000,
"legally_required_deductions": [
{"label": "Federal income tax withholding", "amount_minor_units": 15000},
{"label": "FICA", "amount_minor_units": 7650},
{"label": "State income tax withholding", "amount_minor_units": 4000}
],
"orders": [
{"order_id": "ord-1", "type": "child_support", "arrears_over_12wk": false,
"second_family": false, "claimed_amount_minor_units": 44010},
{"order_id": "ord-2", "type": "creditor", "claimed_amount_minor_units": 30000}
],
"noticed_amounts": [
{"order_id": "ord-1", "amount_minor_units": 44010},
{"order_id": "ord-2", "amount_minor_units": 0}
]
}
},
"id": 3
}
Copy this paragraph into Claude, OpenClaw, or any MCP-aware agent to run this whole workflow on the server and check one field that answers a real question.
Question: Which items of the 250-item population does the public randomness beacon select for testing, so the sample cannot be cherry-picked?
Run the AINumbers MCP tool `run_chain` with {"chain":"beacon-sampled-audit-testing"} and read `art-583-beacon-seeded-fair-sampling-deriver.selected_indices`.
Re-run with `inputs` for `art-583-beacon-seeded-fair-sampling-deriver`, reusing the values that result echoed, with `sample_size` set to 5. Compare the same field.
Verify: call `verify_execution_hash` (https://mcp.ainumbers.co/mcp) with `claimed_hash` set to `composite_execution_hash` and the full `composite_artifact`.
Ledger, for a human re-check: https://ledger.ainumbers.co/
PII rule: send synthetic or anonymised inputs only. The MCP server runs these kernels and logs no payloads.
Chain page: https://ainumbers.co/chaingraph/chains/beacon-sampled-audit-testing.html