The control that checks itself

Before you start

You own one control: every S3 bucket has all four public-access-block flags enabled. This surface is the §6 lab's five-part loop already wired to a scheduler — the thing the real lab's optional task 8 needs a cloud account for. Every scheduled run executes this module's own check library (`ccm-check.sh`, the exact code `labs/setup.sh` generates), ported and CI-verified byte-for-byte against real `bash` runs — the verdicts, evidence records, ledger rows, and alert files are earned from your current simulated cloud state, never scripted. Honesty notes: one tick = 24 hours of schedule (a declared time compression, so a month of monitoring fits in a sitting), and the dashboard tile you watch is a query over the append-only ledger, recomputed every run. On a real machine, §6 walks the same loop by hand: `source ./ccm-lab/ccm-check.sh`, then `evaluate_control` and `emit_evidence` against the committed state fixtures. One more thread to notice: this loop is claim-agnostic. Swap part one for module 00's laptop-encryption claim and part two for the check you scripted in module 01, and nothing else changes — this module is where that check stops being a thing you run and becomes a thing that runs.