Cyber Commons · Course guideA control you cannot evidence is a control you do not have
Somebody signed off on the platform when it was a chatbot. It now moves money, ships code and reads contracts, and nothing in the approval process noticed. A control tested six months ago is not passing — it is unevidenced — and that third state is invisible to most tooling, which is why a register can be entirely green and entirely unsupported.
Build the indicator set: an inventory for the denominator, risk tiering for the target, control mapping for the subject, owners by name, and verification that re-reads rather than citing last year. Then point the same indicators outward at regulators, and run them as a programme sequenced by distance from target.
The unit is the key control indicator: computed from the estate, with a denominator, and a target written before the measurement. F1.13 computes six of them against the CyberTravels repository and returns five gaps and one pass — the pass being what proves the instrument discriminates rather than simply complaining.
Taught duration: about 8 hours (Function A's pace is 16 lessons in 4 hours)
Primary audience: Governance, risk and compliance · risk owners · the CISO office
Prerequisites: Function A, which builds the system this function is about — at minimum A0.0 and A1.0
Reading: 12,415 words of lesson prose, at 180 words a minute.
Fourteen lessons building the framework. F1.0 says what AI governance means and F1.1 is the hinge the other thirty F pages anchor to: from framework control to key control indicator.
Nine lessons mapping your controls outward. The regulatory map, horizontal regulation, voluntary frameworks as a spine, sector overlays, privacy, incident and disclosure obligations, documentation that survives supervision, auditability of autonomous action, and the regulator conversation itself.
Eight lessons on running the programme. Translating risk upward, governing autonomy rather than approving tools, sequencing, org design, the metrics that matter at your level, saying no and saying yes with conditions, building the capability, and resilience over perfection.
Governance, risk and compliance, and the CISO office. GRC analysts, risk and compliance managers, control owners, privacy engineers and BISOs — anyone who has to answer for the estate rather than build it. What changes is what you hand over: a number somebody can compute, with a date on it, instead of a control statement.
Use this on your own, or to run Function F for other people. Everything here serves both; the shaded blocks marked For a room are the only parts a solo reader can skip.
Every per-lesson fact below is generated from the lesson sources and the skills — risk, control, the lab, Day 0/1/2, the measure, the command, and each skill's own committed example run. Unlike the Function A guide, it does not carry a hand-verified transcript of every run: sixteen of those were checked by running them, and writing 133 more without running them would be making them up. Trust the run over this page, and correct scripts/exercises/guides.py.
| On your own | F1 in order and do not skip F1.1 — the anchors on all thirty other pages refer to it. F2 reads as reference material and can be taken by the regimes that apply to you. F3 is the one to read last and twice. |
|---|---|
| With a room | The function most likely to have a mixed room — risk, audit, legal and engineering. F1.10's stakeholder map is worth doing early rather than in sequence, because it tells the room who owns what before they argue about it. |
| Splitting it up | Anything over about four hours is normally split across sittings, and the chapter boundaries are the splits |
| The one sentence to hold | A control you cannot evidence is a control you do not have |
| Chapter | Lessons | What it does |
|---|---|---|
| F1 Building the Governance Framework — Risk and Control | F1.0 · F1.1 · F1.2 · F1.3 · F1.4 · F1.5 · F1.6 · F1.7 · F1.8 · F1.9 · F1.10 · F1.11 · F1.12 · F1.13 | 14 lessons |
| F2 Building the Governance Platform — Regulatory and Compliance | F2.1 · F2.2 · F2.3 · F2.4 · F2.5 · F2.6 · F2.7 · F2.8 · F2.9 | 9 lessons |
| F3 Running the Programme — the CISO Office | F3.1 · F3.2 · F3.3 · F3.4 · F3.5 · F3.6 · F3.7 · F3.8 | 8 lessons |
Half the time? F1.0, F1.1, F1.3, F1.7 and F1.13 from the framework; F2.1 and F2.3 from the platform; F3.1, F3.6 and F3.8 from the programme. That is the indicator argument, the spine argument, and the three programme lessons that change behaviour.
F2.4–F2.8 are reference material. Name them and move on rather than teaching them, unless a sector overlay actually applies to the room.
The same three as every function. Way 1 is the default; the other two matter because a machine with no model configured can still do every lesson, and because "what actually changed?" is the question that comes up most.
| Way | What it does | Needs a model? | Use it for |
|---|---|---|---|
| 1 — in your AI agent | The agent reads the lesson, teaches it, runs the check | No — Claude is the agent | The default for every lab |
2 — scripts/lesson.py <id> | Runs the lesson, prints a five-heading readback | Yes, or it exits 2 saying "no model configured" | Worth doing once in A0.0, to meet that message on purpose |
3 — scripts/checkpoint.py --at <id> --diff | Shows the code this lesson added | No | Any "what actually changed?" question |
This function is about a system Function A builds. You do not have to have built it — a checkpoint writes it for you — but you do need it on disk.
python3 scripts/doctor.py, or python scripts\doctor.py on Windows.python3 scripts/checkpoint.py --at F1.0 --out work/f writes the tree with everything taught up to here and nothing taught after.python3 scripts/install_skills.py --all --lessons F.Read this before the first lesson. A taught session opens with it; alone, read it and move on.
Three chapters: build the framework, build the platform, run the programme. F1 turns framework controls into indicators somebody can compute. F2 maps those outward to the regulations that apply. F3 is the CISO office — sequencing, org design, metrics, and how to say no.
F1.1 is the hinge of the whole function and every F page anchors back to it: from framework control to key control indicator. A control in a framework is a sentence. An indicator is a number with a date on it, computed from an artefact, which is the only form in which a control survives supervision.
The direction of mapping is the argument, and it runs one way only: controls outward to frameworks, never frameworks inward to controls. A programme built per framework builds the same control three times and evidences it none. F2.3 picks the framework that covers the most of your controls as a spine and supplies the remainder from the others.
Each lesson's risk, control, days, measure and skill — and, folded, what that skill prints.
Fourteen lessons building the framework. F1.0 says what AI governance means and F1.1 is the hinge the other thirty F pages anchor to: from framework control to key control indicator.
The arc runs inventory → risk tiering → control mapping → evaluation as evidence → operating versus outcome guardrails → continuous verification → supply chain → lifecycle → stakeholders → model risk → the seams, and ends at F1.13, which computes the indicators against CyberTravels and reports the gaps.
F1.10's stakeholder map is worth pulling forward in a mixed room. It settles who owns what before the room spends an hour discovering it.
A trustworthy-AI statement with no owner per property, so every property is somebody else's job.
One register, risk-tiered, with each property mapped to a control, an owner and evidence that can be re-checked.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| A trustworthy-AI statement with no owner per property means every property is somebody else's job. | Assign each of the seven properties an owner, and read the three chapters as one unit built, evidenced and run. |
Day 2 — measure. trustworthy-AI properties with a named owner (count out of seven; security owns one outright)
The lab. Take the seven properties and assign each an owner in your own organisation. The gaps are the programme.
framework-reference-lookuppython3 skills/regulatory/framework-reference-lookup/scripts/framework_reference_lookup.pyIts output contract requires frameworks, euai_articles, coverage, lookup. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
framework-reference-lookup prints — its own committed example run Art. 14 Human oversight 17 lessons
B1.2 OWASP LLM01 · OWASP T6 · ATLAS AML.T0051 · ATLAS Initial Access · NIST MAP · EUAI Art. 15An annual review certifies nothing about a system that changed the week after it.
Continuous assurance; control effectiveness redefined for probabilistic systems.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| A control tested six months ago is not passing — it is unevidenced, and most tooling cannot represent that third state. | Turn a framework control into something computable, with a denominator and a target written before the measurement. |
Day 2 — measure. the unit itself — a key control indicator (a computation, a denominator and a target; everything else in this function produces, feeds or reports one)
The lab. Change a prompt and show the control evidence going stale in real time.
attestation-signer-lifecyclepython3 skills/attestation/attestation-signer-lifecycle/scripts/attestation_signer_lifecycle.pyIts output contract requires subject, predicate_type, predicate, signatures. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
attestation-signer-lifecycle prints — its own committed example runcontrol age (days) point-in-time continuous
----------------------------------------------------
AC-1 3 PASS PASS
AC-2 9 PASS PASS
SB-1 45 PASS STALE
SB-2 210 PASS STALE
EV-1 5 PASS PASS
DR-1 0 FAIL FAILShadow AI and shadow agents — the inventory is the control most orgs still lack.
Discovery, registration, ownership, risk tiering.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| You cannot govern, tier, test or revoke what you cannot list, and most of it is already in production. | Reconcile three sources — model registry, procurement, and egress logs to provider domains. |
Day 2 — measure. the inventory (the denominator for every other indicator; a share whose denominator is unknown is a count wearing a percentage sign)
The lab. Discover agents from gateway and identity telemetry; build the register.
deployment-inventory-resolverpython3 skills/attestation/deployment-inventory-resolver/scripts/deployment_inventory_resolver.pyIts output contract requires deployment_id, resolved_at, artifacts, missing, orphans, verdict. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
deployment-inventory-resolver prints — its own committed example runasset kind autonomy owner found via
--------------------------------------------------------------------------------------------
fraud-scoring-model model L1 risk-eng registry
support-summariser copilot L1 support-eng registry
vendor-contract-analyser embedded-feature L1 — expense report
unknown-openai-usage-marketing copilot L1 — egress logs
pr-remediation-agent agent L2.5 — egress logs
agent-worker-7f3c agent L2.5 — egress logsAnchor → F1.1. The inventory is the denominator. Every indicator is a share — of agents, of tool calls, of handlers — and a share whose denominator is unknown is a count wearing a percentage sign. An incomplete inventory does not make your indicators wrong; it makes them unfalsifiable.
Tiering by model name instead of by what the thing can do.
Autonomy level × action class × data sensitivity.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| Tiering by model name tracks vendor marketing rather than exposure, and gets the dangerous case exactly backwards. | Tier on autonomy, data reach and blast radius — what the system can do, not what it runs on. |
Day 2 — measure. the target each indicator carries (per risk tier; the same measurement means different things on a tier-1 and a tier-3 agent)
The lab. Tier ten real workflows and assign approval authority.
agentic-risk-tieringpython3 skills/grc/agentic-risk-tiering/scripts/agentic_risk_tiering.pyIts output contract requires scale, assets, by_model, disagreements, questions. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
agentic-risk-tiering prints — its own committed example runasset tier score
------------------------------------------------------------------
frontier chatbot, public docs, read-only low 0
small local model with prod deploy rights critical 12
autonomy L3 (+5)
regulated data (+3)
customer data (+2)
can act externally (+2)Anchor → F1.1. Risk tiering sets the target. The same indicator carries a different threshold on a tier-1 agent that moves money than on a tier-3 one that summarises documents, and F1.1's rule — the target is written before the measurement — is only meetable once the tier exists.
Inventing new controls where an existing one applied to a new principal type.
Map identity, secrets, sandbox, eval and telemetry onto the existing library.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| A framework-first mapping produces a complete checklist that defends nothing, because a clause with no operating control behind it evidences nothing. | Map control to framework, never the reverse, and let coverage fall out as an output. |
Day 2 — measure. mapped controls with an indicator behind them (share of mapped controls; those without are unevidenced and most tooling renders them green)
The lab. Map the B2/B3 controls onto your control library.
control-to-framework-mappingpython3 skills/grc/control-to-framework-mapping/scripts/control_to_framework_mapping.pyIts output contract requires catalogue, mapping, tiers, coverage. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
control-to-framework-mapping prints — its own committed example runcontrol kind satisfies
------------------------------------------------------------------------------------
AC-1 preventive 3 clause(s): NIST AI RMF: GOVERN-1.2
ISO 42001: 6.1
EU AI Act: Art.14
AC-2 preventive 2 clause(s): NIST AI RMF: MANAGE-2.2
ISO 42001: 8.1
SB-1 preventive 2 clause(s): NIST AI RMF: MANAGE-2.1Anchor → F1.1. Control mapping is where an indicator gets its subject. A mapped control with no indicator behind it is the state F1.1 calls unevidenced: it is neither passing nor failing, and most GRC tooling will render it green.
Accepting a vendor's best-of-k demo as assurance; mistaking schema conformance for accuracy.
Read an eval report properly: execution-verified results, reliability across all attempts, trajectory scoring, judge independence.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| A vendor's best-of-k demo is not assurance, and schema conformance is not accuracy. | Report accuracy against a held-out key, with the sample size and an expiry. |
Day 2 — measure. an eval result read as an indicator (sample size is the denominator, the pass bar is the target, the expiry stops it ageing into a claim)
The lab. Take the C2.19 scoring output and turn it into an evidence pack — then find the three ways the same numbers could mislead you.
control-evidencepython3 skills/grc/control-evidence/scripts/control_evidence.pyIts output contract requires control, binding, sample, results, blind_spots, reverification, conclusion. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
control-evidence prints — its own committed example runn 24
conformance 1.0000 ← structural. NOT a quality claim.
expert accuracy 0.8750 ← the number that evidences EV-2
EV-2 PASS
expert accuracy 0.8750 over 24 held-out questions; conformance 1.0000 reported separately; key never exposed to the harness
at +10d → PASS
at +45d → STALEAnchor → F1.1. An eval result is an indicator reading — the sample size is its denominator, the pass bar is its target, and the expiry is what stops it aging into a claim. Read it that way and the conformance/accuracy split stops being a presentation choice: conformance has no denominator worth quoting, so it is not an indicator at all.
Frameworks specify how the system works; regulators care what it produced.
Constrain both, and know which evidence answers which question.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| Shipping only operating guardrails and reporting them as coverage is how a programme passes audit while missing harm. | Separate constraints on how the system runs from constraints on what results are acceptable. |
Day 2 — measure. operating indicators against outcome indicators (two counts; one says the constraint was applied, the other says it worked)
The lab. Classify your own guardrails into the two buckets.
guardrail-specificationpython3 skills/grc/guardrail-specification/scripts/guardrail_specification.pyIts output contract requires rules, coverage, open_commitments. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
guardrail-specification prints — its own committed example runrule kind enforceable
--------------------------------------------------------------------------------------
all agent egress goes through the gateway operating True
privileged tools require approval below L3 operating True
every action is logged with the acting identity operating True
agent identities are separately revocable operating True
no agent action causes unrecoverable customer data loss outcome False
automated remediation does not increase customer-facing incidentsoutcome TrueAnchor → F1.1. Operating and outcome guardrails need different indicators, and confusing them is the most common way a control looks measured and is not. An operating indicator says the constraint was applied; an outcome indicator says it worked.
Automating judgment instead of evidence collection.
Agent-assisted evidence collection, drift detection, exception tracking.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| Point-in-time assurance describes a system that no longer exists by the time anyone reads it. | Re-run the evidence collection inside a freshness window derived from how fast the thing actually changes. |
Day 2 — measure. controls currently evidenced — passing and in window (share of controls; it drops against "controls that once passed", and that is the first honest number)
The lab. Automate one evidence package on a schedule.
aws-runtime-posture-collectorpython3 skills/attestation/aws-runtime-posture-collector/scripts/aws_runtime_posture_collector.pyIts output contract requires deployment_id, collected_at, network, crypto, logging, verdict. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
aws-runtime-posture-collector prints — its own committed example runcontrol state age (days)
------------------------------------
AC-1 PASS 2.0
AC-2 PASS 9.0
SB-1 STALE 31.0
SB-2 STALE 120.0
EV-1 PASS 5.0
EV-2 PASS 12.0Anchor → F1.1. This is the machinery that re-measures. F1.1 argues that a control tested six months ago is unevidenced rather than passing; continuous verification is what shortens that window, and the freshness window per control is itself an indicator.
Vendor AI features enabled by default; sub-processor chains you never mapped.
Questions that actually discriminate between vendors.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| For a hosted model the estate holds no source to measure, so there is nothing to compute an indicator from. | Assess each component on whether it can change without telling you, and accept an attestation with an expiry where it can. |
Day 2 — measure. third-party controls carrying an unexpired attestation (share; a weaker instrument than a measurement, and scored as one)
The lab. Run a real AIBOM against a vendor model artefact.
third-party-ai-assessmentpython3 skills/grc/third-party-ai-assessment/scripts/third_party_ai_assessment.pyIts output contract requires components, versions, control_tests, contract_questions. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
third-party-ai-assessment prints — its own committed example runcomponent kind tier flags
------------------------------------------------------------------------------------------------
cryptography==42.0.5 library low —
langchain==0.2.1 library medium unsigned
hosted GLM-4.6 endpoint hosted model high unsigned, not version-pinned, CAN CHANGE WITHOUT NOTICE
local glm-4.6 weights (pinned digest) weights low —
mcp-jira-connector==0.0.3 tool package high unsigned, runs with agent authority
your controls were tested against a model that changed 5 days ago:Anchor → F1.1. These are the indicators you cannot compute yourself. For a third-party model the estate holds no source to measure, so the indicator becomes an attestation with an expiry — which is a weaker instrument, and worth naming as one rather than scoring it the same.
Re-indexing treated as maintenance, not change.
Retraining, fine-tuning and re-indexing as change-management events.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| A retrain, a fine-tune or a re-index is treated as maintenance, and it invalidates every reading taken before it. | Govern the lifecycle events that raise no ticket, not the ones that do. |
Day 2 — measure. indicators marked stale by a lifecycle event (count; the difference between continuous assurance and a dashboard showing last quarter)
The lab. Write the gate that a re-index has to pass.
agent-lifecycle-governancepython3 skills/grc/agent-lifecycle-governance/scripts/agent_lifecycle_governance.pyIts output contract requires events, identities, consequences. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
agent-lifecycle-governance prints — its own committed example runidentity last auth (d) service running owner finding
--------------------------------------------------------------------------------------------
triage-agent 0 True appsec
patch-agent 1 True platform
legacy-scanner 400 False — orphan — decommissioning never finished
poc-agent-2025 300 False — orphan — decommissioning never finished
sunset-agent 2 False — ACTIVE CREDENTIAL FOR A RETIRED SERVICEAnchor → F1.1. A retrain, a fine-tune or a re-index invalidates a reading. Lifecycle governance is what tells the indicator set that its last measurement is stale, which is the difference between continuous assurance and a dashboard showing last quarter.
Legal, compliance, privacy, cyber and model risk each hold part of the AI control estate and none holds all of it. The programme fails at the seams between them, not inside any one.
A stakeholder operating model naming who decides, who tests, who signs — and where the handoffs leave gaps nobody is watching.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| Five functions each hold part of the AI control estate and none holds all of it, so each assumes another has the middle. | Map who asks what: liability, obligation, lawful basis, containment, fitness. |
Day 2 — measure. one reading, read by five readers (count of distinct questions asked of it; the one nobody asked is the one no indicator was built for)
The lab. Map five stakeholders to the controls each operates, then locate the four classic seam failures in your own estate.
stakeholder-seam-mappython3 skills/programme/stakeholder-seam-map/scripts/stakeholder_seam_map.pyIts output contract requires functions, self_reports, use_cases, seams. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
stakeholder-seam-map prints — its own committed example run compliance 4 controls green
cyber 6 controls green
legal 4 controls green
model_risk 4 controls green
privacy 4 controls green
functions reporting green : 5/5
open seams : 4Anchor → F1.1. One indicator, five readers, five different questions. Legal reads a containment number as liability, model risk reads it as fitness, privacy reads it as exposure. Publishing the reading is not the same as it being consumed, and the question nobody asked is the one no indicator was built for.
The classical model-risk playbook silently breaks once the model can act: conceptual soundness was validated, and then the agent was granted write access nobody validated.
Extend the SR 11-7 lineage — conceptual soundness, ongoing monitoring, independent validation — to non-deterministic, tool-using systems, and name where it still holds.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| The classical model-risk playbook silently breaks once the model can act, because validation was scoped to predictions. | Re-read the three pillars for a model that calls tools. |
Day 2 — measure. ongoing monitoring coverage (share of the model estate; a key control indicator programme in older vocabulary)
The lab. Take a validated model, add one tool, and show which parts of the validation are now void.
model-risk-validation-scopepython3 skills/grc/model-risk-validation-scope/scripts/model_risk_validation_scope.pyIts output contract requires validated, deployed, covers, differences, monitoring, revalidation_triggers. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
model-risk-validation-scope prints — its own committed example runpillar what it asks what it quietly assumes
conceptual_soundness is the method appropriate for the purpose assumes the purpose is stable and stated
independent_validation did someone other than the builder check assumes the thing checked is the thing deployed
ongoing_monitoring is it still performing as validated assumes performance is what changes
All three survive contact with AI. The assumptions are what break.
validation still covers what is deployed: False
tool surface changed: ['db_update', 'read_ticket', 'write_ticket']weight-access-capability-deltapython3 skills/research/weight-access-capability-delta/scripts/weight_access_capability_delta.pyIts output contract requires capabilities, attempts, technique, safeguards, blast. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
weight-access-capability-delta prints — its own committed example runsetting attempts in 24h
------------------------------------------------------
hosted API, 20 req/min 28,800
hosted API, 20 req/min, 5 keys 144,000
local open weights, 1 GPU 691,200
local open weights, 8 GPUs 5,529,600
ratio: 192× more attempts, with no abuse signal reaching anyone.Anchor → F1.1. Model risk management arrived at the same answer decades earlier: SR 11-7's ongoing monitoring is a KCI programme in older vocabulary. The lineage matters because it is the argument that convinces a risk function this is not new.
The handoffs fail, not the functions: privacy assessment into control design, legal position into system prompt, MRM validation into security evidence.
Joint runbooks for the seams — one artefact, many consumers, one owner.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| The functions work and the handoffs leak, and both sides are usually right about their own scope. | Write a joint runbook per seam: one artefact, one owner, named consumers. |
Day 2 — measure. seams with an owned artefact (share of seams; an indicator with two consumers and no owner gets computed twice, differently)
The lab. Trace one artefact across three functions and find the consumer who never received it.
handoff-delivery-checkpython3 skills/programme/handoff-delivery-check/scripts/handoff_delivery_check.pyIts output contract requires runbooks, delivery, undelivered, closure. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
handoff-delivery-check prints — its own committed example runMRM validation -> security evidence
artefact : validation report with tool surface and autonomy
owner : model_risk
consumers : cyber, compliance, internal_audit
legal position -> system prompt
artefact : approved language and refusal set
owner : legalAnchor → F1.1. The seams are where an indicator has two consumers and no owner, so it is computed twice, differently, and the two numbers are used to argue with each other rather than with the estate.
Controls are asserted in a register and never measured, so the first evidence that one was missing is the incident.
Key control indicators computed from source on every change, each gap carrying a named mitigation.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| A control asserted in a register and never measured has no evidence behind it until an incident supplies some. | Compute the indicators from the repository at run time, and report gaps with the lesson that closes each. |
Day 2 — measure. indicators measured against CyberTravels (six — five gaps and one pass; the pass proves the instrument discriminates)
The lab. Measure six indicators against the CyberTravels tree and read the five gaps it reports.
kci-control-measurementpython3 skills/grc/kci-control-measurement/scripts/kci_control_measurement.pyIts output contract requires kcis, gaps. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
kci-control-measurement prints — its own committed example runKCI-01 object handlers that compare an owner == 1.00 0.29 GAP
KCI-05 egress control present == 1 0.00 GAP
KCI-06 no credential literal in the source == 0 0.00 okAnchor → F1.1. This is F1.1 executed. Six indicators, computed from the CyberTravels tree at run time, reported as gaps with named mitigations rather than as a score.
Nine lessons mapping your controls outward. The regulatory map, horizontal regulation, voluntary frameworks as a spine, sector overlays, privacy, incident and disclosure obligations, documentation that survives supervision, auditability of autonomous action, and the regulator conversation itself.
F2.3 is the load-bearing one. Pick the framework that covers the most of your controls, use it as the structure, and supply the remainder from the others.
Much of F2 is reference. Teach F2.1, F2.3 and F2.9, and name the rest unless a specific overlay applies to the room.
One programme per regime; four times the work, none of it joined up.
One control set that satisfies several regimes. Verify current status before relying on any date.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| One programme per regime is four times the work and none of it joined up. | Separate horizontal regulation, sector overlays and cross-cutting law, and map controls outward. |
Day 2 — measure. regimes an indicator can be quoted to (count; they overlap on evidence, not on wording)
The lab. Build the crosswalk for your own sector.
obligation-mappingpython3 skills/regulatory/obligation-mapping/scripts/obligation_mapping.pyIts output contract requires system, layers, obligations, shortest_clock, re_derive_on. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
obligation-mapping prints — its own committed example runclaims-triage-agent — autonomy L2.5, data ['customer', 'health', 'regulated']
instrument layer obligation
--------------------------------------------------------------------------------------------
EU AI Act 1 automated decision affecting individuals; human oversight and record-keeping obligations
DORA 2 ICT third-party risk, incident reporting, resilience testing, exit strategy
HIPAA-equivalent 2 minimum necessary; audit controls
GDPR 3 lawful basis, erasure, automated decision-makingAnchor → F1.1. The reason one control set can satisfy several regimes is that regimes overlap on evidence, not on wording. An indicator computed once is quotable to each of them; a control described three ways is not.
"We only deployed it, we didn't build it" — sometimes true, often not.
Risk classification, GPAI obligations, transparency duties, and how agentic deployment changes classification.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| "We only deployed it, we didn't build it" is sometimes true and often not, and the answer changes what you owe. | Resolve each regulatory theme down to a control from your own catalogue and let its evidence be the answer. |
Day 2 — measure. horizontal themes with a control and an artefact behind them (share of themes; oversight is the hardest because the action completes before a human sees it)
The lab. Classify three workflows and defend the boundary cases.
horizontal-requirement-to-controlpython3 skills/regulatory/horizontal-requirement-to-control/scripts/horizontal_requirement_to_control.pyIts output contract requires themes, evidence, prose_answers, status. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
horizontal-requirement-to-control prints — its own committed example runrisk management system
AC-1 agent identities distinct from human and separately revocable
evidence: gateway logs with an act chain; monthly sample
SB-2 privileged tools require approval below L3
evidence: tool policy in git + denial log
DR-1 behavioural drift raises an alert
evidence: drift alerts and dispositionsAnchor → F1.1. Horizontal regulation asks whether a system is robust, overseen and documented. Each of those becomes a different indicator, and agentic deployment changes which one is hardest — oversight, because the action completes before a human sees it.
Regime-specific mappings with nothing to hang off.
AI RMF / management-system standards as the structure; regulator mappings as overlays.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| Regime-specific mappings have nothing to hang off, so each new law restarts the programme. | Pick a control-shaped framework as the spine and map outward from it. |
Day 2 — measure. indicators the spine already computes that an overlay can reuse (count); gaps the spine does not reach (count, stated plainly)
The lab. Hang two regulator mappings off one framework spine.
framework-spine-selectionpython3 skills/regulatory/framework-spine-selection/scripts/framework_spine_selection.pyIts output contract requires catalogue, coverage, spine, supplements, cost. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
framework-spine-selection prints — its own committed example runframework covers controls
--------------------------------------------------------------
NIST AI RMF 5 ['AC-1', 'AC-2', 'DR-1', 'EV-2', 'SB-1']
ISO 42001 4 ['AC-1', 'AC-2', 'DR-1', 'EV-1']
EU AI Act 4 ['AC-1', 'EV-1', 'SB-2', 'ST-1']
ISO 27001 1 ['SB-1']
DORA 1 ['ST-1']Anchor → F1.1. The framework spine is where indicators attach. Pick the spine first and each regulator's overlay maps onto indicators you already compute; pick the regulator first and you rebuild the set per jurisdiction.
An agent is already a "model" under model-risk rules you already comply with.
Find the regime you're already in before inventing a new one.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| The sector regime you are already in applies to agents without ever using the word AI. | Find the clauses that catch agents: third-party risk, exit strategy, scope containment, minimum necessary. |
Day 2 — measure. thresholds that move, against indicators that are new (two counts; the first is a much smaller job)
The lab. Map one agent to existing model-risk obligations.
sector-overlay-assessmentpython3 skills/regulatory/sector-overlay-assessment/scripts/sector_overlay_assessment.pyIts output contract requires system, clauses, exit, cases. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
sector-overlay-assessment prints — its own committed example runclaims-triage-agent: autonomy L2.5, data ['customer', 'health'], external model True
DORA (financial)
ICT third-party risk your model provider is an ICT third party
exit strategy can you stop using this provider and keep operating?
resilience testing your stop mechanism is in scope for testing
incident reporting clocks measured in hoursAnchor → F1.1. A sector overlay mostly re-targets indicators you already compute — the same containment number against a stricter threshold. The exception is exit strategy, which no horizontal regime asks for and which almost nobody can currently measure at all.
Deletion when the data is in weights, not a database.
Lawful basis, ADM rights, residency in inference and retrieval paths, retention of traces.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| The context window is a disclosure and the trace is a record, so personal data lands in a system nobody reviewed. | Fix lawful basis, retention on the trace itself, and an erasure path that reaches it. |
Day 2 — measure. paths rather than outcomes (where inference ran, what retrieval touched, how long a trace was kept — all three computable)
The lab. Run PII redaction inside the trust boundary with Presidio before anything crosses out.
trace-personal-data-auditpython3 skills/regulatory/trace-personal-data-audit/scripts/trace_personal_data_audit.pyIts output contract requires trace, detections, systems, erasure, retained_lawfully, redaction_at_source. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
trace-personal-data-audit prints — its own committed example runpersonal data present in the agent trace:
step 1 email dana.okonkwo@example.com
step 1 payment card 4111111111111111
step 1 account number acct 8812
step 1 name J. Okonkwo
4 items. Nobody put them there deliberately — the agent read
a support ticket, which is exactly what it was asked to do.row-level-policy-checkpython3 skills/research/row-level-policy-check/scripts/row_level_policy_check.pyIts output contract requires key, tables, credentials_exposed, verdict. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
row-level-policy-check prints — its own committed example runRLS disabled (as shipped) rows returned: 3
@researchbot dana@example sk-REDACTED-openai
@newsdigest sam@example sk-ant-REDACTED
@dealfinder kim@example AKIA-REDACTED-aws
RLS enabled rows returned: 0
signed in as dana@example, RLS enabled: 1 rowAnchor → F1.1. Privacy indicators measure paths rather than outcomes — where inference ran, what retrieval touched, how long a trace was kept. They are computable, and they are the ones most often asserted instead.
Materiality assessed for an autonomous actor with a human-actor playbook.
Coordinate with E2 in hour one.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| The clock starts at awareness and broken attribution consumes it, so containing fast buys no reporting time. | Write the trigger criteria before they are needed, with separate owners for containment and disclosure. |
Day 2 — measure. whether the pre-incident reading existed at all (yes/no; during an incident you are either quoting a measurement or guessing)
The lab. Draft the notification for an agentic incident.
disclosure-phase-breakdownpython3 skills/regulatory/disclosure-phase-breakdown/scripts/disclosure_phase_breakdown.pyIts output contract requires obligation, phases, total_hours, dominant, with_attribution, pre_drafted. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
disclosure-phase-breakdown prints — its own committed example runscenario contain report met margin
------------------------------------------------------------------
attribution sound 2.0 20.0 True 52.0
attribution broken, 3d scope 6.0 92.0 False -20.0
fast containment, slow scope 1.0 80.0 False -8.0
The third row contained in ONE HOUR and missed by 8 hours.
phase hours cumulative noteAnchor → F1.1. A disclosure clock runs on facts you either measured before the incident or are guessing at during it. E5.4 re-measures the indicators after the fix; this lesson is why the pre-incident reading has to have existed at all.
"Explainability" for a system with no deterministic reasoning.
System documentation, data lineage, eval records, oversight evidence, decision logs.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| Documentation that restates intent is what supervision fails. | Make every sentence name a control, an artefact and a date. |
Day 2 — measure. indicator readings carrying a date (share of readings; a narrative describing a control is not evidence it operated)
The lab. Assemble the pack for one high-risk workflow.
supervisory-documentation-scorepython3 skills/regulatory/supervisory-documentation-score/scripts/supervisory_documentation_score.pyIts output contract requires sentences, score, comparison, followups, artefacts_attached. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
supervisory-documentation-score prints — its own committed example run=== WEAK — 0/3 sentences checkable ===
[---] Our AI systems are subject to appropriate oversight and
[---] Access is
granted on a least-privilege basis and reviewe
[---] Agents are
monitored for anomalous behaviour and we main
=== STRONG — 0/6 sentences checkable ===Anchor → F1.1. Documentation that survives supervision is largely indicator readings with dates on them. A narrative describing a control is what supervision fails; a series of measurements is what it accepts.
No trail showing under whose authority the agent acted.
The delegation chain *is* the audit trail.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| Without attribution and replay captured at the moment of the action, neither can be reconstructed afterwards. | Capture the acting identity, the principal and the chain, plus enough to replay the run. |
Day 2 — measure. autonomous actions whose full chain can be reconstructed (share; anything below 1.00 is the part you cannot audit)
The lab. Produce an audit trail from the B2 chain that names authority at every hop.
autonomous-action-auditabilitypython3 skills/regulatory/autonomous-action-auditability/scripts/autonomous_action_auditability.pyIts output contract requires definition, cases, distinguisher. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
autonomous-action-auditability prints — its own committed example runaction merge_pr #8812
acting_identity patch-agent
on_behalf_of dana@corp
chain dana@corp → orchestrator → patch-agent
scopes_held ['repo:read', 'repo:write']
replayable True
replay_gaps []
answerable TrueAnchor → F1.1. The delegation chain is an indicator in its own right: the share of autonomous actions whose full chain — who authorised, on whose behalf, under what scope — can be reconstructed. Anything below 1.00 is the part you cannot audit.
Overclaiming control, or triggering a moratorium.
Explain bounded autonomy with evidence, and anticipate the real questions.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| A supervisor who finds a weakness you did not disclose doubts everything else you said. | Bring the weakest number first, with its denominator and the gaps you already know about. |
Day 2 — measure. coverage stated with stale and unevidenced controls included (share, with the distinction volunteered)
The lab. Defend one workflow in a mock supervisory conversation.
assurance-conversation-preppython3 skills/regulatory/assurance-conversation-prep/scripts/assurance_conversation_prep.pyIts output contract requires evaluation, coverage, openings, known_blind_spots, artefacts. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
assurance-conversation-prep prints — its own committed example runn 20
conformance 1.0000
expert accuracy 0.7500
control state
------------------------
AC-1 PASS
AC-2 PASS
SB-1 STALEAnchor → F1.1. A regulator conversation goes differently when bounded autonomy is presented as numbers that were computed rather than as a description of intent. Bring the indicator, its denominator, and the gaps you already know about.
Eight lessons on running the programme. Translating risk upward, governing autonomy rather than approving tools, sequencing, org design, the metrics that matter at your level, saying no and saying yes with conditions, building the capability, and resilience over perfection.
F3.3 and F3.7 are the two that decide whether a year of work produces control coverage or a set of demos, and F3.8 is the one that says what the programme is actually measured on.
Blast radius explained in engineering terms to a board that needs consequence.
What can happen, how fast, who can stop it.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| A board cannot act on "we found prompt injection"; it can act on exposure, likelihood and a decision being requested. | Drop the mechanism, keep three things, and offer written risk acceptance as a legitimate outcome. |
Day 2 — measure. indicators the board sees (three, chosen from the set that already exists so anyone can re-compute them)
The lab. Convert one blast-radius measurement into a board paragraph.
risk-translation-upwardpython3 skills/programme/risk-translation-upward/scripts/risk_translation_upward.pyIts output contract requires exposure, containment, coverage, findings_version, position. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
risk-translation-upward prints — its own committed example runagent blast radius
----------------------------------------
pr-remediation-agent 44
claims-triage-agent 1
doc-summariser 1
FLEET TOTAL 46
red-team attack success rate (containment surface): 25%Anchor → F1.1. Translating risk upward is mostly choosing which three indicators a board sees. Pick them from the set that already exists, or the board gets a number invented for the slide and nobody can re-compute it.
A per-tool review queue becomes a bottleneck and then a bypass.
A policy on delegated authority instead of tool-by-tool approval.
| Day 1 — what you do |
|---|
| Govern the autonomy level instead: four rungs, each with its own conditions. |
Day 2 — measure. what an agent may do without asking (the autonomy rung, as a function of measured containment rather than of vendor)
The lab. Write the delegated-authority policy.
autonomy-ladder-decisionspython3 skills/programme/autonomy-ladder-decisions/scripts/autonomy_ladder_decisions.pyIts output contract requires ladder, requests, reevaluate_on. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
autonomy-ladder-decisions prints — its own committed example runL1 self-service budget 0 register it; no further review
Assist — model proposes, a human performs every action.
L2 lightweight budget 0 named owner + approval gate on every writer
Act with approval — model calls tools, a human approves each call.
L2.5 governed budget 20 risk tier + blast budget + drift monitoring + tested stop
Act within a blast radius — pre-approved tools, bounded scope, review after.
L3 board budget 60 all of L2.5 + held-out eval per release + board sign-off
Autonomous — model acts and self-verifies; humans see aggregates.Anchor → F1.1. Governing autonomy rather than tools means the policy attaches to indicator thresholds — what an agent may do without asking is a function of measured containment, not of which vendor supplied it.
Starting with the workflow that is most visible rather than most winnable.
Use the maturity model to order investment; choose your first hard "no".
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| Starting with the most visible workflow rather than the most winnable is how programmes thrash. | Sequence by dependency: inventory, identity, containment, evidence, evaluation, continuous. |
Day 2 — measure. nothing is computed here (the order itself is the deliverable — evaluation before identity produces a well-measured system nobody can switch off)
The lab. Sequence your first three workflows and name the no.
programme-sequencingpython3 skills/programme/programme-sequencing/scripts/programme_sequencing.pyIts output contract requires steps, doable_from_start, orders, per_period_output. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
programme-sequencing prints — its own committed example run step name needs unlocks
------------------------------------------------------------------------------------
1 inventory [] you can now tier and assign owners
2 identity [1] per-agent revocation; attribution in logs
3 containment [1] bounded blast radius; a red team has something to test
4 evidence [2] act chains; replayable runs; a drift baseline
5 evaluation [4] accuracy you can defend; regression cases
6 continuous [4, 5] freshness windows; drift alerts; live postureAnchor → F1.1. The order is a dependency order, not a gap-size order, and the indicators are why. Inventory first because it is every other indicator's denominator; evaluation late because a measured system nobody can switch off scores well and cannot be stopped. Sequencing on whichever number looks worst inverts it.
Harness engineering with no home; research as a hobby.
Identity owns the control plane; BUs own grants; security owns stop authority.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| Harness engineering with no home and research as a hobby means the seams have no names against them. | Name an owner for each seam before the incident rather than during it. |
Day 2 — measure. seams with a name against them (share of seams; an unowned measurement exists on a slide and nowhere else)
The lab. Draw your org's ownership map against the topic matrix.
ownership-seam-auditpython3 skills/programme/ownership-seam-audit/scripts/ownership_seam_audit.pyIts output contract requires decisions, unowned, incident, totals, after_assignment. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
ownership-seam-audit prints — its own committed example runseam owner lesson
------------------------------------------------------------------------------
AppSec ↔ Platform platform-security B3.1
Identity ↔ SecOps on-call SRE, pre-authorised B3.6
GRC ↔ Engineering ⚠ NOBODY F3.2
SOC ↔ Data ⚠ NOBODY E1.3
CISO office ↔ Legal legal, on IR notification F2.6
AppSec ↔ SOC detection engineering E2.2Anchor → F1.1. Org design decides who can actually compute each indicator. If identity owns the control plane and nobody owns the measurement of it, the indicator exists on a slide and nowhere else.
Reporting activity instead of exposure.
Inventory coverage, attested-identity share, standing-access reduction, MTT-revoke, blast-radius distribution, eval-gate pass rate.
| Day 1 — what you do |
|---|
| Report five that degrade on their own: exposure, likelihood, assurance, coverage, speed. |
Day 2 — measure. programme metrics that are computed rather than assessed (share; a metric that does not degrade when ignored is measuring activity)
The lab. Instrument the six metrics from your lab stack.
programme-metrics-selectionpython3 skills/programme/programme-metrics-selection/scripts/programme_metrics_selection.pyIts output contract requires candidates, kept, dropped, neglect_simulation. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
programme-metrics-selection prints — its own committed example runexposure fleet blast radius 46 units of unreviewed action
likelihood red-team ASR 25% measured, containment surface
assurance controls evidenced 50% 4/8
coverage agents in inventory 34% 41 of ~120 est.
speed measured time-to-stop 12s game day 41 days ago
metrics that look like governance and are not:
findings closed this quarter goes up with activity; says nothing about posture
training completion % reaches 98% and stays there foreverAnchor → F1.1. These are the indicators, at the level a CISO reports — exposure, likelihood, assurance, coverage, speed. The property that qualifies each of them is F1.1's: it is computed rather than assessed, so it degrades on its own. A number that stays flat under neglect is measuring activity.
Conditional approval that is aspirational rather than enforceable.
Autonomy promotion as an earned event with named evidence.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| Saying no is cheap and usually wrong — the capability ships anyway and you have traded influence for comfort. | Say yes with conditions that are testable, proportionate, few and owned. |
Day 2 — measure. conditions met, each evidenced by an indicator crossing a threshold (count; without one, "yes with conditions" becomes "yes" at the next review)
The lab. Write one enforceable conditional approval.
conditional-approval-designpython3 skills/programme/conditional-approval-design/scripts/conditional_approval_design.pyIts output contract requires request, flat_refusal, conditions, approval. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
conditional-approval-design prints — its own committed example runrequest customer-refund-agent
asks for issue refunds up to GBP 500 without human approval
business case 42% of refund tickets are mechanical; 3.5 FTE of manual work
claimed rung L2.5
blast radius 18 (irreversible, tenant-wide)
risk tier high (score 8)
decision refused
what happens the team ships it as a 'workflow automation' outside the AI registerAnchor → F1.1. Autonomy promotion as an earned event needs named evidence, and named evidence is an indicator crossing a threshold. Without one, 'yes with conditions' becomes 'yes' at the next review.
Hiring for conceptual familiarity instead of practice.
Interview questions that separate the two; internal transition paths.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| Hiring for conceptual familiarity produces a team that can discuss the problem and not measure it. | Staff for the ability to turn a control into something computable, and accept an unglamorous first quarter. |
Day 2 — measure. what the team can evidence, quarter by quarter (per quarter; quarter one produces an inventory and no dashboard, which is the right shape)
The lab. Write the interview loop for an agentic security engineer.
capability-build-orderpython3 skills/programme/capability-build-order/scripts/capability_build_order.pyIts output contract requires required, demoable, orders, warning. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
capability-build-order prints — its own committed example runquarter coverage demoable
------------------------------------------------------
Q1 · inventory + identity 25% 0
Q2 · containment 50% 0
Q3 · evidence + evaluation 75% 1
Q4 · continuous + stop 100% 3
Q1 and Q2 produce nothing demoable. That is the political problem, andAnchor → F1.1. The build curve is unglamorous early precisely because indicators are: quarter one produces the denominator and nothing to demo. The capability being hired for is turning a control into something computable, which is what separates operating a GRC tool from measuring an estate.
Trying to enumerate every failure mode of a probabilistic system.
Maturity measured by containment, detection and recovery — not prevention.
| Day 0 — why it matters | Day 1 — what you do |
|---|---|
| A programme judged on prevention is judged on something a probabilistic system cannot deliver. | Judge it on three capabilities instead: notice, stop, recover. |
Day 2 — measure. containment, detection and recovery indicators (the same three E5.4 re-reads after a fix; prevention has no honest indicator here)
The lab. Re-score your programme on the resilience axis.
resilience-readiness-checkpython3 skills/programme/resilience-readiness-check/scripts/resilience_readiness_check.pyIts output contract requires detection, stop, replay, verdict. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
resilience-readiness-check prints — its own committed example runNOTICE drift 0.500 new tools ['run_shell'] → detected
STOP 12s, tested 41d ago, survives restart True → ready
RECOVER replayable True, scope from the chain ['queue', 'repo-core', 'repo-payments'] → ready
programme containment ASR outcome when containment fails
------------------------------------------------------------------------------------------------
prevention only 0% undetected — found by a third party, weeks later
elapsed to resolution: 720h
prevention + notice 0% detected, cannot halt it — damage continues while you improviseresearch-durability-checkpython3 skills/research/research-durability-check/scripts/research_durability_check.pyIts output contract requires claims, backlog, durability, lost, closure_definition. The script validates the reply against these, so a run that answers in the wrong shape fails rather than passing quietly.
research-durability-check prints — its own committed example run=== folklore — actionable: False ===
CLAIM our review agent can be tricked by comments in diffs
SETUP the review agent
TRIGGER a comment
OBSERVED it approved something it shouldn't
RATE not measured
HOLDS WHENAnchor → F1.1. Resilience is measured by the containment, detection and recovery indicators — the same ones E5.4 re-reads after a fix. Prevention has no honest indicator on a system that changes weekly, which is why the maturity model does not use one.
Have the engineering and the risk halves of the room each write the same indicator independently, then compare. The gap is usually the artefact, not the definition.
Cover the answer column, or use any three with a room.
| Question | Answer |
|---|---|
| 1. What turns a framework control into something you can report? | An indicator: a number, from a named artefact, with a date on it |
| 2. Which direction does control-to-framework mapping run, and why? | Controls outward to frameworks — inward builds the same control three times and evidences none |
| 3. When is a control operating rather than merely watched? | When something enforces it, not when something documents it |
| 4. A model was retrained. What happened to your control evidence? | It is unevidenced — not failed, which is a different and more honest state |
| 5. What starts the regulatory clock? | Awareness, not confirmation |
| 6. Why is a flat no expensive? | The capability ships anyway and you lose the visibility — F3.6 |
| What you built | Goes on to | Where it is taken apart |
|---|---|---|
| The indicators you defined | F1.13 — Measuring the controls on CyberTravels — gaps and mitigations | get computed against CyberTravels, gaps and all |
| The programme you sequenced | F3.8 — Resilience over perfection | gets measured on resilience rather than on perfection |
| Pitfall | What to do | If you are running it for a room |
|---|---|---|
| Mapping frameworks inward to controls | It builds the same control three times and evidences it none. F2.3 is the lesson: your controls are the spine, frameworks are the labels. | This is the derail that costs the most time in a mixed room. |
| Treating a control as operating because it exists | F1.6 separates operating from watched. A control is operating when something enforces it, not when something documents it. | — |
| Reporting a control as evidenced against behaviour that has changed | F1.7 and F1.9: a retrain, a fine-tune or a re-index invalidates a reading. The control has not failed — it is unevidenced, which is a different and more honest state. | — |
| Answering a regulator with coverage instead of accuracy | F2.9 rehearses the three openings that actually get used. Conformance and expert accuracy get reported separately or not at all. | — |
| Reading F3 as the soft chapter | F3.3's sequencing and F3.7's build curve are the two lessons that decide whether a programme has control coverage or demos at the end of a year. | — |
| When | Prompt |
|---|---|
| Starting a lesson | Summarise lesson <id>'s Risk, Control and Day 0/1/2 in plain English, under 100 words. |
| See what changed | Run scripts/checkpoint.py --at <id> --diff and explain the changed lines like I'm new to Python. |
| Predict before "Your turn" | Before you run it: here is my prediction for the Your turn change: <prediction>. Now run it and tell me if I was right. |
| Stuck on an error | Show me the exact error, what it means, and the smallest fix. Don't change anything else. |
| Check understanding | Quiz me with 3 questions on lesson <id>. Don't give answers until I reply. |
| Connect to the attack side | Which Function B lesson attacks what I built in <id>, and how, in two sentences? |
| When something will not run | Run scripts/doctor.py and tell me only the lines that are not ok, with the fix for my operating system. |
| Term | In one line |
|---|---|
| Agent | Software that plans, calls tools and acts on what it reads |
| Harness | The loop around the model: context in, tool call out, result back |
| Verifier | Code, not a model, that checks a result before it is accepted |
| MCP | Model Context Protocol — a standard way for agents to reach tools |
| Sink | Somewhere data can do damage |
Audience (aud) | The one server a token is valid at |
| Scope | The one permission a token grants |
| Workload identity | A name for a piece of software, e.g. spiffe://…/agent/workflow |
| Token exchange | Swapping a user token plus an agent identity for a short, narrow, per-action token |
| A2A | Agent-to-agent messaging |
| Span / trace id | One recorded step of a run / the id that joins all of them |
| Canary token | A credential that looks real and that nothing legitimate ever uses |
| Blast radius | What one run can reach and damage before a human can stop it |
| Conformance vs. accuracy | Whether the answer has the right shape vs. whether it is right |