AIGovOps Beacon Level 100 · Framework Lab
Level 100
0% complete
Level 200 →
Workshop promise · 30 minutes

Become a Beacon Framework Auditor.

Find every AI. Sign what matters. Hand the auditor a bundle. In the next 30 minutes you will discover AI use, inspect signed receipts, map a real failure to controls, and leave with a reusable audit workflow.

By the end of this level you'll be able to:

  1. Launch Beacon in browser or local workshop mode.
  2. Identify what Beacon discovered and what belongs in scope.
  3. Explain what a signed receipt proves — and what it does not.
  4. Export and verify an auditor bundle.
  5. Map one real-world AI failure to controls, frameworks, and missing evidence.
Section 1 of 7

Why Beacon exists.

○ mark complete

Most AI governance today is "a PDF and a meeting." Beacon answers the auditor's real question: what AI models are running, who is using them, what version is in use, what data is involved, and where is the evidence?

Beacon does this through two front doors:

  • Beacon Studio — a five-step auditor-friendly workflow for non-engineers.
  • Beacon Control Plane — raw event streams, exports, and policy-as-code outputs for power users.

This level walks the Studio path. Level 200 takes the Control Plane.

Section 2 of 7

What ships in the box.

○ mark complete

Beacon's five documented layers — each one is something an auditor can ask about and verify.

LayerWhat it does
Discovery Detects AI usage through passive DNS/HTTP scan, proxy hooks, cloud account scans, CSV import, and an optional endpoint agent.
Inventory Turns detections into rows: vendor, model, version, occurrence count, users, first seen, last seen, environment, and evidence pointer.
Transaction tracking Creates Ed25519-signed receipts in append-only NDJSON. Prompt and result are stored or hashed. Hourly Merkle anchoring for tamper-evidence.
Checklists Packs for NIST AI RMF, EU AI Act Article 13, ISO/IEC 42001, HIPAA-for-AI, Human Flourishing — plus 18 more in the full registry.
Policy as Code Emits gate YAML, OPA/Rego, a Governance Decision Record, and a signed bundle. Builder-to-auditor bridge.
Section 3 of 7

The five-step Studio.

○ mark complete

Beacon Studio is the non-technical front door. Same evidence model as the Control Plane — different wrapper. Tap each step to see the facilitator prompts for both tech and policy audiences.

1 What network are we looking at? ›

Paste a domain, upload a CSV, or connect a cloud account. Beacon then looks for AI models running there.

Tech team prompt
Which discovery surface would you get approved first?
Policy team prompt
Which source would best satisfy an internal audit inventory request?
2 Beacon is looking — discovery and inventory. ›

The inventory model includes vendor, model, version, occurrence count, users, first seen, last seen, environment, and evidence pointer. Each row is something the auditor can interrogate.

Lab action. Pick one discovered system and answer:

  • What is it?
  • Who likely owns it?
  • Why would an auditor care?
3 Pick what matters. ›

Workshop mode lets you tap the rows in scope. Each row is explained in plain English, including examples like GPT-4o usage counts and team context.

Tech language
Which row looks like technical debt — active without clear ownership?
Policy language
Which row likely affects regulated data, rights, safety, or human outcomes?
4 Pick your guardrails. ›

Beacon includes checklist packs for NIST AI RMF, EU AI Act Article 13, ISO/IEC 42001, HIPAA-for-AI, and Human Flourishing. The default workshop set is NIST + Human Flourishing (with EU AI Act when discussing higher-risk scenarios).

FrameworkTechnical framingPolicy framing
NIST AI RMF Repeatable control and risk-management model you can operationalize. Structured way to show risk identification, governance, and treatment.
ISO/IEC 42001 Management-system pattern for AI governance operations. Evidence that AI governance is systematic, not ad hoc.
EU AI Act Article 13 Changes transparency and documentation requirements for higher-risk systems. Creates information duties that need inspectable evidence.
Human Flourishing Keeps human acceptability visible in the control flow. Adds a human-impact test, not just a compliance test.
5 Here's your audit. ›

The final screen is a traffic-light checklist, the receipts behind each green check, and a Make it Policy as Code button. The workshop ends with a concrete package of evidence and next-step policy artifacts — not with a static discussion.

Teaching line. Policies are promises. Controls are proof. The Make it Policy as Code button turns the promise into the proof.

Section 4 of 7

What a signed receipt proves.

○ mark complete

Each observed interaction becomes a replay-style receipt containing: user identity, UTC timestamp, model, version, prompt or hash, result or hash, an Ed25519 signature, append-only NDJSON storage, and hourly Merkle anchoring.

A receipt is not a dashboard event. It is a portable, signed, challengeable claim about what happened, when, and under whose authority.

Live receipt sandbox

key · pending No network. Everything runs in your tab.

Press Generate Ed25519 key to begin.

Public key (base64) 
—
Key fingerprint (first 16 bytes of SHA-256, base64-URL no-pad) 
—
Receipt JSON (what you signed) 
—
Canonical bytes (JCS sorted keys, no whitespace) 
—
Ed25519 signature (base64-URL) 
—

—

Receipts signed this session

    Receipt-review field guide

    Open one receipt and identify these five fields. Then answer the prompts.

    FieldTech promptPolicy prompt
    model · version Which belongs in SIEM and incident response? Which fields demonstrate traceability?
    environment Belongs in release gates. Demonstrates scope of accountability.
    timestamp Used for replay and forensics. Demonstrates when oversight occurred.
    signature The thing your CI/CD can verify. The thing that survives outside the product UI.
    verify area What you re-run in a partner team. What the auditor takes home.

    Teaching point: evidence should travel. Auditors should not need privileged console access to test claims.

    Section 5 of 7

    Map a real failure to controls.

    ○ mark complete

    Five curated cases from the 100-failure dataset — three technical, two policy-facing. For each one, identify the harm, the framework that applies, the Beacon artifact that would have caught the gap, and the YES-act. You can save your answers (browser only — nothing leaves this tab) or print the worksheet PDF and fill it in by hand.

    Open printable worksheet ↗ Worksheet PDF ↓

    Case 1 — Boeing 737 MAX MCAS software fatal crashes (2018-2019)

    Sector: Auto/Mobility·Damage: $2.5B DOJ resolution·Act: YES-Ship

    Root cause — Boeing concealed a safety-critical MCAS design change from regulators and pilots; the certification process failed to catch that the system could repeatedly command nose-down trim from erroneous sensor data.

    The receipt that would have caught it — a checklist receipt requiring explicit sign-off on the safety-critical MCAS change, plus a scoring report highlighting the unresolved risk of a hidden control-law update before deployment.

    Case 2 — Knight Capital deployment failure (2012)

    Sector: Finance·Damage: $440M in 45 minutes·Act: YES-Steady

    Root cause — A deployment failed to push updated code to one of eight servers. The stale code interpreted new order-routing flags as legacy commands, generating runaway orders that bankrupted the firm in less than an hour.

    The receipt that would have caught it — deployment attestation receipts per host, plus a control gate requiring all-server confirmation before the new flag could be enabled in production.

    Case 3 — Detroit wrongful arrest via facial recognition (2020)

    Sector: Public sector·Damage: civil suit, policy reform·Act: YES-Recover

    Root cause — A face-recognition match produced a single candidate; police arrested Robert Williams based on that match alone. No human review, no documented thresholding, no audit trail of the model version or training data.

    The receipt that would have caught it — a transaction receipt per match showing the model version, confidence score, and required-human-review flag; absence of the named human approver should have blocked downstream action.

    Case 4 — Apple Card credit limit bias allegations (2019)

    Sector: Finance·Damage: NY DFS investigation·Act: YES-Steady

    Root cause — Couples with similar finances saw very different credit limits, including in the same household. Goldman/Apple could not explain the decisions or demonstrate disparate-impact testing.

    The receipt that would have caught it — per-decision receipts tying input features to outputs, plus checklist receipts demonstrating ongoing fairness testing as a required control rather than an aspirational one.

    Case 5 — Robodebt automated welfare debt scheme (Australia, 2016-2020)

    Sector: Public sector·Damage: AUD 1.8B settlement, Royal Commission·Act: YES-Ship

    Root cause — An automated income-averaging algorithm was deployed against welfare recipients without legal authority, generating false debts at scale. Operational decisions were made by automation without documented review or recourse.

    The receipt that would have caught it — a pre-deployment governance gate requiring legal sign-off on the algorithmic method, plus per-debt receipts with appeal and human-review fields demonstrating fair-process compliance.

    Want all 100 cases? Level 200 includes the full interactive deep-dive with framework cross-links, harm-type filters, and per-case Beacon artifact recommendations.

    Section 6 of 7

    Check yourself.

    ○ mark complete

    Five questions. Your answers are saved in this browser only.

    1. What does a Beacon receipt prove?

    A receipt is portable and verifiable outside Beacon — that's what makes it survive contact with auditors and regulators. Dashboards and meeting notes don't.

    2. Which of these is NOT one of Beacon Studio's five steps?

    The Studio walks discovery and audit. Deployment approval lives in the Policy-as-Code path (Level 200), not the Studio itself.

    3. What's actually IN an auditor bundle?

    The bundle is self-contained — anyone with openssl can re-verify it offline. The VERIFY.md walks them through it. No vendor login, no phoning home.

    4. Which Beacon artifact would have caught Boeing's MCAS failure?

    MCAS was concealed from regulators and pilots. A checklist receipt would have forced an explicit, signed acknowledgement of the change before flight.

    5. How do you verify a bundle without Beacon installed?

    The whole point of the bundle is portability. Stock openssl is enough to test the signatures.
    Score · 0 / 5 0 answered
    Section 7 of 7

    Completion standard.

    ○ mark complete

    You've completed Level 100 when you can say all four statements clearly.

    Self-attestation

    Level 100 complete.

    You can now find every AI, sign what matters, and hand the auditor a bundle they verify themselves. Continue to Level 200 for the Suitcase Lab, the nine 20-minute lab variants, the Policy-as-Code emission, the receipt API, and the full 100-failure deep-dive.

    Start Level 200 →