OpenChainGraph Suite · OCG v0.8.13 · Audit & Assurance

Beacon-Sampled Audit Testing

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.

OpenChainGraph · 3 Nodes, 2 Gates compliance control Hash-Anchored §4 · §21.4 Gated Commit-Then-Pulse Ceremony Client-Side · Zero PII
Not an audit opinion, not a sampling-adequacy determination, and not a regulatory filing. The beacon pulse, its round and its randomness are SUPPLIED by the caller and treated as asserted: no step here fetches a pulse, and no step verifies the pulse's BLS signature, so a sample is only as trustworthy as the pulse supplied and the manifest hash committed before it. Sample size and risk limit are the caller's methodology, not this chain's. Running this chain produces evidence about a selection and a recomputation; it does not by itself discharge any sampling duty under AU-C 530, AS 2315 or any regime's testing requirement.

The ceremony, and why the order is the whole point

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.

  1. Freeze the population, then hash it. Enumerate the items eligible for testing (payroll rows, pay periods, invoices, loan files) into a manifest with a stable order. Hash the manifest. Nothing is selected yet, so there is nothing to steer toward.
  2. Publish the manifest hash before the pulse round exists. This is the load-bearing step. The hash goes somewhere dated and outside the auditor's control (an engagement letter, a filing, a timestamped receipt, a counterparty's inbox) while the beacon round that will seed the draw is still in the future.
  3. Take the pulse when it arrives. Read the round number and randomness from drand quicknet or a NISTIR-8213 beacon. Nobody involved in the audit produced that value, and by the time it exists the manifest is already fixed.
  4. Derive the sample (stage 1). art-583 runs the HMAC-DRBG walk and emits the drawn indices plus a per-draw transcript covering every candidate, accepted and rejected alike. A reviewer replays the identical selection offline from the manifest hash, the pulse and the algorithm id alone.
  5. Recompute the drawn population (stage 2 or 3). The regime's recompute node runs on the selected items and reaches its own verdict against what was reported. That verdict travels with the selection transcript in one composite artifact.
Reverse steps 1 and 3 and the evidence value collapses. A manifest assembled after the pulse is known can be shaped until the draw lands somewhere comfortable; a pulse chosen after the manifest is fixed can be shopped round by round for the same effect. Committing the manifest hash first closes both, and it closes them for the auditor's own benefit: the defence against an accusation of cherry-picking is the same artifact as the defence against actually doing it.
§4 Execution Hash · Workflow Definition Anchor
execution_hash:computing…
Workflow Stages · 3 Nodes · Gated Linear (OCG v0.8 §21.4)
1 ROOT · SELECTION node
Beacon-Seeded Fair-Sampling Deriver art-583-beacon-seeded-fair-sampling-deriver
Derives the selected item indices and the full per-draw HMAC-DRBG transcript from three declared inputs: the manifest hash committed before the pulse round, the pulse itself, and the algorithm id. SHA-256 and HMAC only, no clock and no randomness of its own.
gate · /verdict → DERIVED continues to the configured recompute; anything else takes the default and the automated path ends. An underived sample is not a population worth recomputing, and the chain says so rather than testing whatever was lying around.
MCP Call · 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
}
https://mcp.ainumbers.co/mcp
2 CONFIGURATION 1 · PREVAILING WAGE node regime configuration
Certified Payroll / Prevailing Wage Recomputation art-574-certified-payroll-prevailing-wage-recompute
Recomputes the sampled certified-payroll rows against the declared wage determination, with CWHSSA overtime at time-and-a-half on the basic rate and fringe due straight-time for every hour, then compares the recomputed required gross against a submitted payroll where one is supplied.
gate · /verdict → INDETERMINATE means this run declared no certified payroll to test, so the chain falls through to the garnishment configuration of the same ceremony. MATCHES or DIVERGES is the tested result and takes the default, ending the automated path.
MCP Call · 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
}
https://mcp.ainumbers.co/mcp
3 CONFIGURATION 2 · GARNISHMENT · TERMINAL node regime configuration
Multi-Garnishment Stacking Recomputation art-572-multi-garnishment-stacking-recompute
The identical ceremony pointed at a different population. Recomputes, for the sampled pay periods, how much of disposable earnings each order in the declared stack may lawfully withhold under its own statutory cap, and compares that against a garnishment notice where one is supplied. Terminal stage.
MCP Call · 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
}
https://mcp.ainumbers.co/mcp
Where This Ceremony Comes From · Dated Observations
NISTIR 8213 (Draft) · A Reference for Randomness Beacons: Format and Protocol Version 2. Names public auditability of randomized processes among the applications a beacon exists to serve, and specifies the signed, hash-chained pulse this chain consumes as a declared input. Draft published May 2019; read 2026-08-08. Still at initial-public-draft status on that date.
Colorado Election Rule 25.2.2(i), 8 CCR 1505-1 · the risk-limiting-audit random seed is established at a public, live-streamed meeting, each digit of a 20-plus-digit seed drawn by a sequential roll of a ten-sided die, only after counties have filed the ballot manifests the seed will select from. Commit-then-pulse, run at state scale. Rule cited as in force 2026-08-08; Colorado opened the 2026 primary RLA on 2026-07-13.
drand quicknet (League of Entropy) · the beacon treated as primary here: threshold BLS, no single operator, sub-three-second rounds. This chain reads a round number and randomness the caller pasted in; it does not fetch, and it does not check the BLS signature. Characteristics as published 2026-08-08.
AU-C 530 / AS 2315 · both sampling standards ask that selection give sampling units a chance of selection and that the sample be expected to represent the population. Beacon seeding is one way to evidence how selection happened. It is not a substitute for the sample size, risk limit or judgement the standards also require. Read as in force 2026-08-08; the pack takes no position on sampling adequacy.
Export Workflow Artifact
Download a §4-compliant workflow artifact with execution hash and step definition. Hash is deterministic over canonical {policy_parameters, output_payload} per RFC 8785/JCS.