Controls testing · 2026-09-01 – 2026-09-30
The controls page says what the 21 controls are. This page is the binder behind it: whether each was tested, how, against what population, with what sample, and with what result — including a worked example that passed and one that did not.
Six rules shaped every workpaper in the binder behind this page.
Every control is checked against five fixed design attributes — trigger, actor, action, record produced, and frequency — each pointing to the artifact that plays that role, never to a filename.
Each attribute is marked present, partly present, or absent, with the reason stated. A control can be well designed and still fail in operation, or vice versa — the two are scored separately.
Before anything is tested, the full population the control should have covered is defined and counted, from the system's own records.
An automated control that fires on every event gets one re-performed instance plus a configuration-unchanged check; a daily job gets five days sampled across the month; a manual control gets up to five events, or all of them if there are fewer.
Every control lands on exactly one of six conclusion strings, never a free-text verdict.
Effective · Effective with exception(s) · Deficient · Not operated in period · Not testable (policy only) · Design only (no TOE possible). The vocabulary is fixed in advance so a conclusion can't be worded to sound better than the evidence supports.
Every claim of what a control does, or what it found, is checked against the actual artifact — the running code, the log line, the committed history — not against a description of that artifact written somewhere else.
A document describing a safeguard is not the safeguard. Citing the document that makes a claim does not confirm the claim; the underlying mechanism has to be read or re-run directly.
Every automated safeguard this binder relies on was deliberately broken, in a throwaway copy, to prove its safety test actually turns red when something is really wrong — not just when a script runs.
The method: copy the safeguard outside the live system, break it on purpose, confirm the test fails, restore the original, and confirm nothing in the live system changed. A test nobody has ever watched fail is not evidence of anything.
This page is built from the private testing binder by a generator that runs a leak test on its own output, never by redacting the private binder in place.
A fixed list of private, licensed, or confidential paths was never read while building this page. The generator refuses to publish prose that leaks a name, a local path, a session identifier, or other sensitive material.
1 Effective · 14 Effective with exception(s) · 3 Not operated in period · 3 Not testable (policy only) · 1 Design only (no TOE possible). 35 exceptions · 5 observations · 168 evidence references in the private binder.
Underlined terms like hook are engineering shorthand; hover, focus, or tap one for a plain-language definition — or switch on Explain the tech above to read the whole page that way. Audit vocabulary (population, sample, exception, and the like) isn't translated; it's assumed familiar.
A detective, manual control: the builder re-scores every risk in the register each quarter and on trigger events, compares what is left against a written tolerance, and names a tracked treatment for each risk outside it.
Every review instance required in the period: scheduled quarterly reviews due 2026-09-01 to 2026-09-30, plus trigger events (a risk realizing; a new autonomous surface added). Reviews performed: 1 (2026-09-29). Trigger events located: 1 (a partial realization of one risk, same day). Scheduled due dates in period: 0. Completeness cannot be fully established for the new-surface trigger, because no dated list of autonomous surfaces exists to enumerate against.
All: the single review instance of 2026-09-29.
10 attributes passed and 2 took exceptions: the review's next-due date, and the treatment tracking for one risk.
Effective with exception(s)
Effective with exception(s) — the control operated once in the period as designed: 14 risks re-scored before and after control, compared to a written tolerance, published with the independence limit stated, and 6 of 7 out-of-tolerance risks traced to a tracked work item. The evidence does not support the 'sets the next due date' attribute unambiguously, or a tracked treatment for one risk; and nothing here tests the quality of the ordinal judgments, which the register itself disclaims.
9 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A directive, manual control: plain-language procedures describe how a change is proposed, reviewed, built, verified and recorded; how each class of change is rolled back; which actions cannot be rolled back at all; and how an agent, job, hook or script is retired. They are reviewed when the watched-path table changes and quarterly.
Review events required in the period: (a) each change to the watched-path table 2026-09-01 to 2026-09-30 — 0 (the table's file had 2 commits in September; both diffs change the spec-matching logic, not the table); (b) each quarterly register review in period — 1 (2026-09-29). Total required reviews: 1. Complete: the table lives in one version-controlled file, and the register's review log is the only review record.
All: the single required review (the 2026-09-29 register review).
2 attributes passed (the procedures exist, dated and version-controlled; they cover every element), 1 attribute was not applicable (no watched-path change in period), and 1 took an exception (no review line at the 2026-09-29 register review).
None.
Effective with exception(s)
Effective with exception(s) — the procedures the control requires exist, were written and committed inside the period, and cover every element the register names, including the irreversible-action list and job/agent/hook retirement. The evidence does not support the review attribute: the one review trigger that fired in period left no dated review line, and the documents have no place to record one. The watched-path-change trigger had no instance to test.
7 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A directive, manual, point-in-time control: a privacy impact assessment inventories categories of personal data (never the data itself), maps the surfaces data flows to and from, and grades perimeter, minimisation and flow awareness separately.
Assessment instances (full or re-run) performed 2026-09-01 to 2026-09-30: 0. One maintenance edit in period (2026-09-07; 3 lines added, 3 removed, noting the retirement of a scheduled content watcher). Complete for the artifact: an assessment performed elsewhere and not written into this document would not be a privacy impact assessment under the control's own evidence definition.
Not applicable — no instance in period to sample. For record, the pre-period instance of 2026-08-07 was walked through in the test of design.
No instance in period. For record, the 2026-08-07 instance passed the three design attributes tested (categories not data; flow map; three separate grades); the standing artifact drew 1 observation on currency.
None.
Not operated in period
Not operated in period — the assessment exists (2026-08-07), is well-formed against the control's own activity text, and contains no raw personal data on the samples tested; nothing re-ran it in September, and its top-ranked residual exposure no longer matches the register's record of the same risk. The evidence supports the artifact; it does not support the artifact as a description of the system on 2026-09-30.
6 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A directive, manual control: the mission and a short list of objectives are written down, each objective has a measure and a status taken from data, they are published on the governance page, and an objective the data cannot support is marked unmeasured or unmet.
Quarterly reviews of mission and objectives due in the period: 0. The objectives were written on 2026-09-29; the register re-score that day is their baseline, not a review. Next review due 2026-12-29. Complete: the governance data and its rendered page are both version-controlled and there is no other place a review could be recorded.
Not applicable — no instance to sample. The 2026-09-29 creation was walked through in the test of design.
No review instance in period. For record, the 2026-09-29 creation passed (mission and four objectives with measure and status, published) and O3's data-derived status re-performed to the register.
None.
Not operated in period
Not operated in period — the mission and four objectives exist, are published, carry a measure each, and report status honestly (three 'Not yet measured', one 'Not met' that re-performs to the register). No quarterly review has fallen due since they were written on 2026-09-29, so there is no operating instance to test; the first will be the 2026-12-29 re-score.
7 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A preventive, automated gate that blocks any write to a privileged path unless a written spec names the path or a reviewer agent has recorded a clean audit within the last two hours.
Two populations from a scan of every session record in the period (1,688 records): 58 gate denials (36 by the shell gate, 14 on edits, 8 on new-file writes) and 1,378 passed writes to watched paths (1,253 edits, 125 new files), of which 327 edits were under the 200-character exemption and 1,051 needed a spec or a marker. A first, looser scan found 288 hits; 230 were reads of the gate's own source or probe output, not decisions. Session records are the only record of decisions, so the population is complete only to the extent the records are.
Fifteen items: 5 passes that needed a spec or marker and 5 size-exempt passes drawn haphazardly with a fixed seed, plus 5 denials chosen to cover both gate hooks and three watched labels.
All 10 passes still clear today on the rule that cleared them (a dated spec line or the size exemption); 4 of 5 denials now clear through a spec added after the block, in order; 1 denial, on a messaging-integration instructions file dated 2026-09-18, was followed under a minute later by a successful write with no recoverable reason; 0 marker overrides were used in the period.
None.
Effective with exception(s)
Effective with exception(s) — across 58 denials and 1,378 passes every re-performed decision matched the gate's rule, two of three test suites went red when the gate was broken in a sandbox, and no override was used; but the control keeps no decision record, so the one anomaly cannot be explained and a future reviewer will have less population than this one.
10 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A preventive, automated hold: when the weekly reconciliation job auto-applies a change to a foundational rule, it commits with a hold tag, and the nightly commit-and-push job skips the offsite push while any held commit is under 48 hours old.
Repository commits in the period whose subject carries both the hold tag and the reconciliation-job prefix: 0 in the period and 0 in the repository's whole history. The reconciliation job ran on 2026-09-06, 2026-09-13, 2026-09-20 and 2026-09-27 and auto-applied nothing on each run, so no held commit could exist.
No items; the population is empty.
No operating instance to test; the design is in place and the skip branch is covered by a unit test that was not mutated in this testing.
None.
None.
Not operated in period
Not operated in period — the design is in place and the skip branch is unit-tested, but no held commit has ever existed, so there is no evidence the control works end-to-end in production; reliance rests on the test and on reading the code.
7 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A detective, automated control: every night a scheduled job commits the working system to a private remote and commits the agent-control layer to its own local repository.
The 30 calendar nights of the period, each expected to produce one dated commit in each repository. Vault: 26 nights with a nightly commit (one night has two), 4 nights without — 2026-09-01, 2026-09-03, 2026-09-09, 2026-09-28. Agent-control repository: the same 26 nights and the same 4 missing. Of the 55 scheduled jobs loaded on the machine, 10 job definitions are under version control and 45 are not.
Every seventh run night plus the period end (5 of 26 run nights) for push and content, and all 4 missed nights examined.
All 5 sampled commits ran at the scheduled hour under the job's identity and are on the remote. 2026-09-03 failed on a repository lock held by a live session, was recovered by a manual sweep the same morning, and a retry was shipped that day. 2026-09-01, 2026-09-09 and 2026-09-28 have no commit in either repository and no retained run record.
None.
Effective with exception(s)
Effective with exception(s) — on 26 of 30 nights the job committed both repositories at the scheduled hour and pushed the vault, and every sampled commit is on the remote; one failed night is explained and remediated, three are unexplained because the only run log is volatile. The record of changes is good; the record of the record is not.
8 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A detective control, half automated: new skills and commands default to test-first with a companion suite, an advisory hook nudges any new one written without a suite, and the builder's standing method proves each check can fail by breaking a sandbox copy and confirming the suite goes red.
Skills and commands added to the agent-control repository in the period, excluding 13 vendor-synced skill files: 4 authored items (2 commands, 2 skills). Day-granular, since the repository is committed nightly. For context, the command library holds 28 commands, 6 with a companion suite and 22 without.
All 4 (population of five or fewer).
3 of 4 items were born with a suite on the same day, each suite carrying its own mutants; 1 skill was created on 2026-09-07 and gained its suite on 2026-09-14, seven days later, with no nudge delivered; 0 rendered nudges appear in 1,688 session records.
None.
Effective with exception(s)
Effective with exception(s) — three of four new automations in the period were born with a suite that carries its own negative control and the fourth caught up within a week, but the automated nudge that makes this the default has an output channel the agent never reads, and the only evidence it works is a suite that asserts the text rather than the delivery.
6 evidence references cited in the private binder for this control (not shown here — see Provenance below).
Two pre-execution hooks inspect every shell command the agent issues and block recursive force-deletes, bulk-delete idioms, and any deletion of a cloud-document pointer file before the command can run.
Every shell command in the period that one of the two hooks blocked: 172 blocked destructive commands plus 1 blocked cloud-pointer deletion (173), found by scanning every session-record file for the period (963 files, 367,904 records). A second, negative population: the 3 executed commands in the period whose text contains the recursive-force delete idiom, from the executed-command audit log. Completeness cannot be established: the session record is the only place a block is written, and sessions run on another model provider fire no hooks.
Every-34th item of the 172 (5), the single cloud-pointer block, all 3 audit-log items, and 2 live instances observed on the fieldwork date 2026-10-01: 11 items.
All 6 sampled period blocks and both fieldwork-date instances reproduce against the live hooks; 2 of the 3 executed audit-log commands carry the idiom only as prose; 1 executed command is a true bypass.
Effective with exception(s)
Effective with exception(s) — Both hooks were registered for the whole period with unchanged configuration, every sampled block reproduces, and every suite relied on was shown red under mutation; one recursive force-delete executed through a case-arm shape the classifier does not parse, so the objective is not fully met and the exception stands.
10 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A pre-execution gate blocks any shell command that would change many files at once until a manifest keyed to that exact command lists each file with its own reason; sends, publishes, deploys, and spend require the owner's explicit yes as a written policy with no hook behind it.
Every shell command in the period the bulk-change gate blocked: 19, from the same session-record scan (963 files, 367,904 records). An independent second trace: 9 manifest files carry September names in the manifest store. Completeness carries the same caveat as AC-01.
Every-4th item of the 19 (5) plus 1 live instance on the fieldwork date 2026-10-01: 6 items.
3 of 5 sampled period blocks reproduce today; the other 2 are explained by digest-matched manifests of 21 and 69 per-file lines written 65 seconds and 22 seconds after their blocks; the fieldwork-date instance blocked this tester's own test harness and no manifest was written.
Effective with exception(s) / Not testable (policy only)
Effective with exception(s) for the bulk-change gate: registered all period, configuration unchanged, sampled blocks reproduce or are explained by the designed manifest path, suite shown red under mutation, but the objective's human-approval wording is not what the mechanism enforces. Not testable (policy only) for the send and spend half, as the register itself discloses.
9 evidence references cited in the private binder for this control (not shown here — see Provenance below).
The messaging-channel listener acts only on messages from a single allowlisted sender, and a remote run-now trigger resolves only to a fixed map of scheduled jobs that must also be loaded, with a fixed argument list that never includes input text.
Inbound messages in the period and those dropped as non-allowlisted; run-now entries and those rejected. Both unobtainable: sender drops write nothing, the listener log has 0 period lines and no per-message records, and the run-now queue lives on a remote endpoint outside this binder's read scope. Operation in the period is evidenced only indirectly: a chat-state file written on 2026-09-30 by code that runs only after the sender check, and a listener process alive since load.
No period items possible. Fieldwork-date re-performance on 2026-10-01 only: 5 synthetic attribute checks and 1 mutation.
All 5 synthetic attributes pass and the mutation shows red; no period instance could be tested.
Design only (no TOE possible)
Design only (no TOE possible) — The sender allowlist (1 id) and the two-sided, fixed-argument job trigger are implemented where the register says, were unchanged in the period at the lines that matter, and were re-performed and shown red on 2026-10-01 in a stubbed sandbox; no operating population exists because sender rejections are not recorded and the listener log is untimestamped and boot-scoped.
10 evidence references cited in the private binder for this control (not shown here — see Provenance below).
An hourly watchdog reads the fleet health table, restarts any scheduled job that has gone silent or stale, escalates once if the restart fails, and a status dashboard regenerates every 15 minutes.
Watchdog runs with a run header dated in the period: 549 of 720 scheduled hours, with two days having no run at all. Dashboard regenerations: 269 recorded from 2026-09-28 to 2026-10-01; earlier runs are unobtainable because the generator logs to temporary storage that the 2026-09-28 reboot cleared.
Every one of the 549 run summaries was classified; the single stale-job event in the period was walked end-to-end; all 7 blind runs were enumerated.
Detection, restart, single escalation, fail-closed blind handling and the dashboard's 15-minute cadence all passed; hourly coverage, the mute after one escalation, and the dashboard's healthy badge on a dead job are exceptions.
Effective with exception(s)
Effective with exception(s) — the watchdog detected the one stale job in period within the hour, reloaded it, escalated once when the reload failed, and its fail-closed branch is mutation-tested; it then went silent on a job that is still dead, the dashboard rendered that job healthy, and 24% of hourly slots have no run.
15 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A scheduled detector classifies every automation run by its actual output, not its reported status, catching runs that claimed success but produced nothing useful.
The population was every scheduled scan of the real automation output during the period that the control existed (it was installed partway through the period) — 167 scans across 22 days — covering 82 real automation output files.
All six hollow-run hits that occurred in the period were re-read in full, and the detector's run cadence was checked across every day it existed.
From the day it was installed, the detector scanned on schedule every three hours and caught all six real failed automation runs in the period — runs that had reported themselves as successful despite producing almost nothing useful, or an outright provider error. Five of the six hits were larger than the simple size threshold and were only caught because a second check inspects the output's content for an error, not just its size. Each hit produced exactly one alert, with no repeat noise. A deliberate break-it test on a sandboxed copy of the detector's logic confirmed the safety check actually catches a real mistake, not just a cosmetic one.
None.
None.
Effective
Effective — from the day it was installed, the detector scanned on schedule, correctly classified six real failed runs by their actual output rather than their claimed status, alerted once for each, and its classification logic is proven to catch a real break when deliberately tested. The first part of the period predates the control's existence.
7 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A shared wiring check lets a hook's test suite assert that the hook is registered under a matcher that fires for today's tool name, and fails closed when the checker is missing.
Hook test suites that call the shared checker: 6 of 30 hook suites (70 suites exist in total across hooks and scripts; 46 distinct hook scripts are registered).
Both suites the register names (the destructive-command blocks and the bulk-change gate) run in full; the checker re-performed against the live configuration and two mutated copies.
The checker is correct on live and mutated configurations and both named suites pass; coverage is 6 of 30 hook suites and no record exists of when any suite last ran.
None.
Effective with exception(s)
Effective with exception(s) — the shared checker correctly reports wired, matcher-miss and unwired on live and mutated configurations, and the two suites the register names use it and pass; it covers 6 of 30 hook suites, and nothing records when those suites last ran.
6 evidence references cited in the private binder for this control (not shown here — see Provenance below).
Significant failures get a structured root cause — criteria, condition, cause, consequence, corrective action — and the corrective action becomes a tracked item.
52 root-cause invocations in the period, from the skill-invocation ledger; 11 root-cause record files with period dates; 128 closed dispatched records all-time, of which 74 carry a date and at least one named artifact.
Full re-run of the produced-versus-wired measurement over all 74 adjudicable records, plus a haphazard sample of 5 of the 11 period records screened for the Five Cs and for the disposition of each guard they name.
Runs happen, produce artifacts, and each sampled record has a tracked item; the corrective action reaches a registered guard in 5 of 74 cases, two sampled records cite guard files that no longer exist, and one lacks labelled consequence and corrective-action sections.
None.
Effective with exception(s)
Effective with exception(s) — root-cause runs happen (52 in September), produce structured records with the Five Cs in 4 of 5 sampled, and each has a tracked item; the corrective action reaches a registered guard in 5 of 74 cases, so the objective is met and the risk the control addresses — the same failure recurring — is largely not.
7 evidence references cited in the private binder for this control (not shown here — see Provenance below).
Before a file-edit tool call on a shared register, a hook snapshots the register to temporary storage; the nightly commit provides the daily offsite copy.
Snapshots surviving with a period date: 62, all from 2026-09-28 to 2026-09-30; snapshots from 2026-09-01 to 2026-09-27 are unobtainable, cleared by the 2026-09-28 reboot. Offsite: 26 of 30 nights with a daily commit; missing 2026-09-01, 09-03, 09-09 and 09-28.
Re-performance of the hook with a synthetic edit on a register (expected one new snapshot) and on a non-register (expected none); full enumeration of surviving snapshots and of commit nights.
The hook snapshots a register on edit and ignores a non-register, and the 62 surviving snapshots match register edits; the 2026-09-01 to 09-27 snapshots are gone, the hook could not fire on edit before 2026-09-14, shell and multi-edit rewrites are never snapshotted, and 4 nights lack an offsite commit.
None.
Effective with exception(s)
Effective with exception(s) — the hook takes a pre-image on write or edit of a register, re-performed with a negative control, and the nightly commit provides a daily offsite point for 26 of 30 nights; snapshots for 2026-09-01 to 09-27 are gone with the 2026-09-28 reboot, the hook could not fire on edit before 2026-09-14, and shell and multi-edit rewrites are never snapshotted.
7 evidence references cited in the private binder for this control (not shown here — see Provenance below).
An end-of-turn hook blocks any agent turn that changed something, claimed the work was done, and verified nothing in the same turn.
Every end-of-turn decision the hook logged between 2026-09-01 and 2026-09-30: 6,017 decisions, counted twice by independent commands with the same result.
Every 7th blocked turn in log order, first 5 taken; plus the full set of 192 blocks tabulated by day.
All five sampled blocks fired as designed; blocks are present on 25 of 30 days; 2 of 6,017 turns passed on a parse failure, which is the exception.
Effective with exception(s)
Effective with exception(s) — the hook is registered at the end of every turn, logged 6,017 decisions and 192 blocks across 25 of 30 days, the sampled blocks each show the three-condition rule applied, and the suite goes red when the block is removed. Two fail-open turns are the exception; the false-positive rate in the sample and the unrecorded mid-period changes are observations.
None.
7 evidence references cited in the private binder for this control (not shown here — see Provenance below).
Public pages are built from curated material, never by redacting the private system in place; where a build has a leak test, the test blocks the build on real names, local paths, or account identifiers.
Builds of public pages committed to the site repository in the period, for the surfaces that carry a test: the learnings page 4 commits, the controls page 8, the governance page 3, the home page 9, the play page 1. Denominator for coverage: 21 distinct public pages in the site's public allowlist.
All tested surfaces re-performed today on a fresh render, plus the two in-period ship records (2026-09-29 and 2026-09-30) cited for their own leak-test runs.
The leak test is green on every in-period build of the three covered surfaces and goes red on planted leaks; the runner as a standing control is red since 2026-09-30 and partly unmeasurable today.
Effective with exception(s)
Effective with exception(s) — on the three surfaces that carry a standing leak test, the test is build-blocking, was green on every in-period build, and goes red on planted leaks today. The exceptions are that the cross-page runner has been red since the 2026-09-30 ships and that two of its check families cannot execute in the current environment; the measured coverage gap (13 of 21 pages untested) is a design observation the register already states, now with a number.
8 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A standing rule that every item the system surfaces carries an origin label (requested by the owner, raised by an agent, fixed by self-healing, produced by a hook or scheduled job, or origin unknown); nothing mechanical enforces it.
Not definable: 'surfaced item' has no mechanical boundary, so no population can be drawn.
None; test of operating effectiveness not performed. An advisory scan was run instead and is not asserted on.
Not tested; the advisory scan found 16 labelled replies among 3,908.
None.
Not testable (policy only)
Not testable (policy only) — the rule is written and nothing records, counts, or enforces it, so there is no population to test and no check that can fail. The advisory scan (16 of 3,908 substantial replies labelled) suggests the policy is seldom applied; that is an observation for the register, not a tested result.
None.
3 evidence references cited in the private binder for this control (not shown here — see Provenance below).
Workflows billed per API call must state an estimated cost per unit and get a yes before they run; a scheduled audit checks daily for exposed API keys and weekly for token burn, but does not measure spend.
Preventive half: metered API runs in the period — cannot be established, because no spend measurement exists to enumerate them from. Detective half: scheduled audit runs in the period — 29 daily security-mode lines (expected 30; 2026-09-28 missing, corroborated by the job's own stdout log) and 4 weekly full-audit lines.
Preventive: whole-population search of September session records for a real cost estimate. Detective: all 33 audit lines read.
The weekly audit ran 4 of 4 times but never measured spend; the daily audit ran 29 of 30 days; the preventive estimate-and-approve step could not be tested because no metered run can be identified and no estimate was found.
Not testable (policy only)
Not testable (policy only) — the preventive half (estimate + approval) is a rule with no record and no identifiable population of metered runs; the detective audit ran 29 of 30 days and 4 of 4 weeks but, with no administrative credential, never measured spend. The control as written cannot be shown to operate against its own objective.
9 evidence references cited in the private binder for this control (not shown here — see Provenance below).
A daily scheduled job diffs the remote host's tool interface against the previous snapshot and flags tools renamed, added, or removed; state lives in plain files so vendors can be swapped, and a written procedure covers model deprecation.
Daily runs from 2026-09-01 to 2026-09-30: 31 fires on 30 distinct days (one re-fire hit the idempotence skip), with 28 snapshots written; no day missing.
All 30 days classified by outcome; every delta line and every fatal line read.
Ran 30 of 30 days, completed 27 with a diff, caught both real host changes; 3 days produced no diff, 4 pre-fix flap lines, 3 post-fix flap lines.
Effective with exception(s)
Effective with exception(s) — the diff ran on all 30 days, detected the two real host changes in the period (2026-09-10 and 2026-09-11) and flagged them, and its predicate is covered by a suite with its own mutation arms. Three days produced no diff (loud failures), and the post-fix flap shows the exclusion predicate still admits one class of false positive.
10 evidence references cited in the private binder for this control (not shown here — see Provenance below).
One control where the test passed cleanly, and one where it found a real gap. Both are walked through the same five steps: define the population, select the sample, re-perform, result, conclude.
The control's scheduled scan ran every three hours against every automation's recent output; the period in scope was every scan from the day the control was installed through the end of the test period, covering 82 real output files.
Every one of the six real hits the detector caught in the period was read in full, rather than a smaller slice, because six was a small enough number to check completely.
Each hit was read against the detector's two-arm rule — output too small, or output containing a provider-level error at any size — to confirm the rule, not just the detector's label, actually applied.
All six hits were confirmed correctly classified: five were caught by the content check even though they were larger than the simple size threshold, and each produced exactly one alert, with no repeat noise across roughly 160 later scans.
Effective — from the day it was installed, the detector scanned on schedule, correctly classified six real failed runs by their actual output rather than their claimed status, alerted once each, and a deliberate break-it test on a sandboxed copy of its logic confirmed the safety check catches a real mistake, not a cosmetic one.
Every shell command in the test period that this safeguard actually stopped: 172 blocks of a recursive force-delete, plus one block of a cloud-document deletion.
Eleven items were sampled: five blocks spread across the month, the one cloud-document block, three lines found in a separate command log that happened to mention a force-delete, and two fresh re-performances on the day of testing.
Each sampled command's exact text was re-run against the live safeguard. Of three suspicious log lines, two turned out to be harmless descriptive text; one was a real destructive delete that had executed without being stopped. The real delete was wrapped inside a case-statement arm — a conditional branch in the shell script — and the safeguard's classifier only inspects the first word of each command segment, which in this shape is the branch's own keyword, not the delete itself.
Six of six sampled blocks reproduced correctly when re-fed to the live safeguard today. The one real miss executed because of the case-statement-arm shape. The safeguard's own standing proof that it has 'zero fail-open results' uses the same first-word logic that missed this case, so it cannot, by construction, see this class of gap.
Effective with exception(s) — the safeguard was in place all period, unchanged, and every sampled block reproduces today; one recursive force-delete executed through the case-statement-arm shape, so the objective was not fully met for this one pattern. A fix has been filed (2026-10-01) and has not yet landed as of this page's most recent render.
Testing is not neutral — doing it changed some claims this system made about itself.
This page is built from the private testing binder by a generator that runs a leak test on its own rendered output. No fenced or licensed source was read while building it. Numbers on this page are cited to the binder by section, in a separate claims manifest, not retyped by hand.
Tester the system's own agent, inside the system it governs.
Reviewer vacant. No independent review has been performed on this binder.
Build structured fields (ids, titles, conclusion strings, counts) are extracted mechanically from the private workpapers and hashed; prose is authored by hand at role level and checked for required plain-language pairs before this page is generated.
Every technical term used on this page, defined in plain language. Hover, focus, or tap any underlined term above for the same definition inline.