Case study
Security operations & governance
A ruling checks the live host before it decides. Both layers write to one audit trail. The publish gate can refuse.
Context
One host carries the client work, the financial data, the automation and a public identity. There is no staging tier and no containment tier, so every severity call is made against a total blast radius, and the severity policy is written that way.
The register is the spine. Each entry is numbered and carries a severity, a state and the date it was last checked against the live host. Entries close by re-checking, not by time passing, and where an entry has never been checked the register records that rather than carrying a date.
Two rules govern how the register is used. A live check outranks memory — a register is a record of what was true when somebody last looked, so a resumed session re-runs the line before acting on it. And the officer function is separated from the execution function. One layer decides what tasks exist and what severity they carry; the other runs the runbooks. Both write through the same event dispatcher, so there is one trail rather than two — and the dispatcher records an event type it does not recognise as an unknown event rather than quietly accepting it as a known one.
What I built
A ruling has a fixed four-part shape, and the checking comes before the verdict. The most recent one opens with six live checks run against the box rather than against the register, states the verdict in one paragraph with the residual risk named by class, attaches twelve numbered requirements all marked mandatory, and closes with an eight-item post-arm checklist to be run attended — output pasted into the record before the surface counts as live. Arming without the checklist is a breach of the ruling, not a shortcut.
Three mechanisms do the load-bearing work under it.
Inbound is denied at two independent layers, because the container daemon writes its own firewall chain that is consulted before the host chain — a rule in one place only is a rule that can be walked around.
A silent configuration override was neutralised by ordering rather than deletion. The daemon resolves directives first-value-wins, and a vendor-supplied drop-in was being read before the administrator's own file, so the intended setting never applied and reading the main file would never have shown it. A second drop-in, named to sort ahead of it, is read first and wins. The replacement access path was demonstrated live first, timestamped, before anything was changed.
Untrusted documents are converted only through a wrapper: safe mode, a throwaway per-call profile, a sandbox with private temp and process isolation. Where a separate network namespace was unavailable, a 92-line seccomp filter enforces the same denial one layer down, refusing internet-family sockets outright.
Nothing here has been tested by an adversary.
The anatomy of a ruling — four parts, and the register entry it creates the same day
Decisions
Chose to deny inbound at two independent layers over one clean rule in the host firewall, because the container daemon writes its own chain that is consulted before the host's user chain — a single rule in the wrong layer is bypassed by the layer above it.
Chose to neutralise a silent configuration override by adding a drop-in that sorts ahead of the vendor file over deleting that file, because the daemon resolves directives first-value-wins and the earlier-sorting drop-in is therefore the one read first: deletion fixes today and re-breaks on the next provisioning event, while ordering makes the intended value win either way — and the ruling carries a standing watch item to re-read the resolved configuration, not the file, after any provider event.
Chose to make a missing secret scanner a hard failure with no opt-out flag over letting the gate skip a check it could not run, because a scan that did not run did not pass — the one optional check reports WARN inside a loud block and the documentation states WARN means the check produced no findings to show, never coverage.
Evidence
Research artifact · evidence ledger
| Claim | How it was checked | Status |
|---|---|---|
| The standing register holds 21 numbered exposures, each carrying a severity and a state. 18 of the 21 also carry the date the claim was last checked against the live host; the three that do not are two standing structural entries and one the register itself marks as never verified. States resolve to 4 OPEN, 4 CONTROLLED, 3 ACCEPTED, 1 PARTIAL and 1 CLOSED, with the remainder carrying compound states. | grep -oE 'SR-[0-9]+' <register> | sort -u | wc -l → 21 ; grep -E '^\| SR-[0-9]+' <register> | grep -cE '20[0-9]{2}-[0-9]{2}-[0-9]{2}' → 18 rows carry a last-checked date ; grep -oE '\| (OPEN|CLOSED|CONTROLLED|ACCEPTED|PARTIAL)' <register> | sort | uniq -c → the state mix | published |
| The decision log is append-only, 510 lines, and holds 4 dated rulings — one ruling being one dated section — the earliest dated 2026-07-23 and the most recent 2026-08-23, inside a file whose earliest referenced date is 2026-03-30. Two of the four carry an explicit approve-with-conditions verdict; the other two are an investigation plan and an execution record. | grep -cE '^## 20' <decisions> → 4 ; wc -l <decisions> → 510 ; the earliest and latest dated section headers in the same file → 2026-07-23 and 2026-08-23 ; the earliest date token anywhere in the same file → 2026-03-30 | published |
| The most recent ruling carries the four-part shape drawn above: 6 pre-ruling live checks numbered V1–V6, 12 numbered conditions all marked mandatory, and 8 post-arm checks numbered P1–P8 to be run attended. | grep -cE '^\| V[0-9]' <decisions> → 6 ; grep -cE '^[0-9]+\. \*\*' over the ruling's condition block → 12 ; grep -cE '^- \[ \] \*\*P[0-9]' <decisions> → 8 ; grep -nE '^### [0-9]\.' <decisions> → the four-part shape ; the block's own heading states MUST for all twelve | published |
| The incident log is separate and append-only, with 4 entries under a fixed vocabulary: 2 confirmed, 1 benign after investigation, and 1 documented negative result — a hunt where every candidate proved already patched, kept because the method lesson was worth keeping. | grep -cE '^- \*\*20' <incidents> → 4 | published |
| One audit trail carries both layers: 353 machine-appended entries across 2,051 lines, on 143 distinct days inside a 146-day window. The dispatcher every actor writes through recognises 12 event types and records anything else as an unknown event rather than accepting it. | grep -cE '^ - timestamp:' <audit> → 353 ; wc -l <audit> → 2051 ; grep -oE '20[0-9]{2}-[0-9]{2}-[0-9]{2}' <audit> | sort -u | wc -l → 143 ; grep -cE '^ [A-Z_]+\)' <dispatch> → 12 | published |
| The host sensor is one file, 1,611 lines, standard library only, scoring 10 named layers on a weighted average. On an ordinary day it makes 288 three-layer passes, 96 ten-layer passes, 24 janitor runs, 24 outbound-only linter runs and 1 daily digest — four different units of work that are never summed into one number. | wc -l <sensor> → 1611 ; the layer table and weight table in the same file → 10 layers ; the schedule lines that drive it → 5 / 15 / 60-minute modes plus the daily digest | published |
| The gate is the required last step before this site is published: 7 checks defined, of which 6 run in fixed order on every publish and a 7th runs when an evidence bundle is passed, exiting non-zero if any one of them fails, and the tree it guards carries the origin declaration the gate demands. Its rule file carries 43 rules in five categories — 11 topology, 5 identity, 16 content-legal, 6 disclosure, 5 tone — and 2 of those categories have their matched text redacted in the gate's own output, so the log cannot leak what it caught. Self-excluded paths are printed on every run, including passes. | grep -c '^def check_' <gate> → 7 ; the check list the gate assembles before running → 6 unconditional, 1 appended only when an evidence bundle is given ; a rule-array count over <denylist> → 11 / 5 / 16 / 6 / 5 = 43 ; grep -n 'REDACT_CATEGORIES' <denylist> → 2 categories ; the origin declaration the gate reads for same-origin resolution is present at the root of the tree this site is built from | published |
| The document-render sandbox is a 405-line wrapper, a 92-line seccomp filter and a 180-line policy whose single rule is that calling the raw converter is an incident. The filter inspects the domain argument of the socket call and refuses the two internet families, so a crafted document cannot fetch even where a separate network namespace is unavailable. Running the filter's self-test under the same BPF program returned both internet families denied with EACCES and the local family allowed. | wc -l over the wrapper, the filter and the policy → 405 / 92 / 180 ; grep -nE 'AF_INET|__NR_socket|EACCES' over the filter source → the denial ; the filter's self-test, which installs the same BPF program and then opens sockets under it, was run on 2026-08-23 → AFINET=DENIED, AFINET6=DENIED, AFUNIX=OK, exit 0. | published |
| The container control plane is built default-deny: the backend never mounts the container socket and speaks to a scoped proxy that allows 6 verb groups, denies 17, and itself publishes no port. Its security document publishes 7 residual risks against itself, and the states are published rather than netted: 3 still open, 1 recorded closed pending live verification, 2 accepted, 1 tracked as belonging to another surface. The panel is built and checked, not permanently deployed. | count of allowed and denied verb-group flags in the panel's compose file → 6 and 17 ; grep -cE '^\| \*\*R[0-9]' <panel-security> → 7 ; the status column reads 4 OPEN, 2 ACCEPTED and 1 tracked separately, and the as-built section then records the first of those four closed pending live verification ; the panel's own status line records built-and-checked, not deployed | published |
12 claims tested · 9 published · 3 withdrawn before publication. Full evidence record available on request — king.hippopotamus@yahoo.com.
Limitations
Nothing here is a penetration test, a third-party review or a certification. Every finding is self-assessed and the documents say so. The claim is a documented posture, not an absence of compromise — the incident log holds two confirmed incidents.
The sensor score is not a coverage figure and must not be read as one. The register entry that carries it records that the headline score overstates real coverage, so a green reading is not evidence of coverage. Re-baselining is deliberately manual, which is what makes an unexplained change meaningful and what makes a stale baseline possible.
The controls on the automation surface are procedural by design: they are written rules that agents consult, and this page claims no technical enforcement layer behind them.
This is not continuous monitoring with forensic readiness. Forensic coverage is carried on the register as an open item, not a closed one. Alerting is deliberately wrapped so a delivery failure cannot break collection, which also means a failed alert is silent.
The container control plane is built and checked, not permanently deployed. Of the seven residual risks its own security document publishes against itself, three are still open, and the one recorded as closed is closed pending a live re-check that has not been run.
The gate is the required last step before this site is published, not a guarantee about everything already public. Artifacts published before the gate existed never passed through it, and nothing the gate does can retract what was already distributed.
Links
No demo — there is nothing to open. This apparatus governs a private operating environment, and the artifacts it produces — the register, the rulings, the incident log — carry addresses, container names and topology on every line and cannot be shown. The commands that produced every figure are published instead, on the record page. Full evidence record available on request — king.hippopotamus@yahoo.com.
Authorship
I am the architect and author of record; drafts were produced by agent tooling under my protocol and every sentence was approved by me before publication. The permission matrix, the charter, the register, the rulings, the incident log, the sensor, the render sandbox and the publish gate are mine, written and operated over 4 complete months; agents execute runbook steps and log through the same dispatcher I do, and the officer function — what tasks exist, what severity they carry, what gets approved — is not delegated to them. Every figure on this page was re-run read-only on 2026-08-23; the redactions are the publish gate's.
Author approval — 2026-08-23, hash dc3a6635