ops-warden/history/2026-08-29-layer-model-v04-review.md

# Security Layer Model v0.4 — ops-warden's review

**Date:** 2026-08-29
**Reviewed:** `net-kingdom/canon/standards/security-layer-model_v0.4.md` (accepted)
**Prior position:** `ADR-0010`, assent to v0.1 (`WARDEN-IN-0001`)
**Outcome:** no objection to the ruling; three findings, one of them against ops-warden.

---

## What v0.4 did with ops-warden's amendment

Both §5 asks from `ADR-0010` were adopted.

**§5.3 declared engine gap** is the amendment ops-warden offered, adopted with the
four fields intact (`capability`, `intended_owner`, `blocked_on`, `review`), the
rationale preserved — *a rule offering no lane for a real sanctioned case gets
satisfied by relabelling rather than by closing the gap* — and the framing that
matters most kept explicit: **a declared gap is tracked non-conformance, not
conformance**. ops-warden's delegation machinery is cited as prior art.

**§5.2 conduit** resolves the question ops-warden flagged rather than assumed. The
test is the supplied-authority property, which is the right test: it turns on what
the repository presents, not on what it touches. *"A conduit that presents its own
token is not a conduit"* is a sharper statement of `ADR-0002` than `ADR-0002` makes.

**This created an obligation ops-warden had not met.** §5.3 requires the fields
*machine-readably* and §11 makes the mapping a mechanical check; ops-warden's
declaration was prose in `INTENT.md`. Fixed in this pass: `layer.yaml`,
`scripts/check_layer_conformance.py`, `tests/test_layer_conformance.py`. The
checker found three undeclared modules on first run, all false positives — help
text, a docstring, and the doubles library that *simulates* `bao` — which is why
it now matches invocation shapes rather than the word.

---

## Finding 1 — §9.1 and §5.3 disagree, and ops-warden's §4 row is the instance

§9.1: *a Staff repository MUST NOT be catalogued in §4 as owning a capability that
requires a Tooling contact no engine exposes*; where intended but unbuilt, the
entry **MUST be marked pending** and the gap declared under §5.3.

ops-warden's §4 row reads `operational access lanes, stewardship, runbooks; SSH
certificate issuance` — with no pending mark. And §13 lists *SSH-CA signing write
(`VaultCA`, `bao kv put`) — declared by ops-warden — intended owner secrets-engine*.

So the catalog asserts ownership of a capability that requires a Tooling contact no
engine exposes, unmarked. By §9.1's own text that is a defect. But the available
fix is worse than the defect: **marking it pending would be false.** SSH issuance is
production-verified and in daily use. `pending` would tell a reader ops-warden does
not yet do the one thing it demonstrably does.

The root cause is that §9.1 collapses two different states:

| State | Example | Capability today |
| --- | --- | --- |
| No route exists at all | kings-guard containment (§9.2) | **zero** |
| Route exists via a declared §5.3 gap | ops-warden SSH issuance | **working, tracked** |

§5.3 exists precisely to sanction the second. §9.1 was written for the first — it
was raised by kings-guard, about containment, and correctly fixed *for that case*.
Applied to the adjacent case it produces a false catalog.

**Recommendation:** give §9.1 two marks rather than one — `pending` where no route
exists, and `declared-gap` where the capability is discharged under §5.3 and
registered in §13. Both are honest; today's binary forces a choice between a false
label and an unmarked violation.

This is the §12 loop working as designed, and §12 already says so: a finding that a
rule is unsatisfiable is a success of the loop.

---

## Finding 2 — §5's scope is undefined for infrastructure §4 does not catalogue

§5 forbids *a direct client for a Tooling-layer system*. §4 catalogues the security
estate, and only `key-cape` and `OpenBao` are Tooling rows.

ops-warden holds an HTTP client for the **State Hub** and for **llm-connect**
(`src/warden/worker.py`). Neither appears in §4. Both are infrastructure a Staff
repository holds a direct client for.

The question is not rhetorical, because the answers diverge sharply:

- **If they are Tooling**, then every Staff repository in the estate is in
  undeclared violation on adoption day — they all write progress events — and
  §11's second mechanical check fails estate-wide.
- **If they are not**, §5 should say so, because *"a Tooling-layer system"* reads
  considerably broader than *"a repository in the §4 Tooling rows"*.

ops-warden has recorded both under `non_tooling_clients` in `layer.yaml` with the
reasoning stated, rather than resolving it unilaterally. The scope is gate-house's
to set.

---

## Finding 3 — §9.6 lands on ops-warden, and ops-warden does not satisfy it

This is the one against us, and it is the most consequential item in the review.

§9.6 consequence 1: *any system whose evidence is load-bearing MUST make emission
atomic with the state change it records. An archive cannot retrofit completeness.*

**ops-warden's audit emission is deliberately non-atomic.** `src/warden/ca.py:90`
carries `pass  # audit must not block signing`, and `wiki/AuditTrail.md` states the
trail *"never blocks the primary action"*. If the audit append fails, the
certificate is still issued and the event is simply lost — a suppressed event that
leaves the chain perfectly intact, which is the exact failure §9.6 describes.

That was a considered availability choice: an audit-disk problem should not remove
production host access. §9.6 now makes it a conformance question, and the trade is
real in both directions:

- make emission atomic → an audit write failure fails the sign, and the estate's
  operational access lane acquires a new dependency on its own evidence store;
- leave it → signing evidence cannot be treated as complete, and anything reasoning
  from *"there is no record of a sign"* is unsound.

**ops-warden has not changed it, and is not going to decide this alone** — §9.6 is
estate doctrine and the question is whether SSH signing evidence is load-bearing in
gate-house's sense. What ops-warden can say is that the second horn is currently
true and undocumented: `wiki/AuditTrail.md` does not warn that absence of a record
is not evidence of absence. That correction is ops-warden's regardless of the
ruling, and is the smaller half of the fix.

Note also that §5.2 requires a conduit action to be *"reconstructable as the
caller's action in audit"* — an audit-dependent claim, and therefore bounded by
§9.6. Worth a cross-reference so the two rules do not drift apart.

---

## Offered

`layer.yaml` + `check_layer_conformance.py` + `test_layer_conformance.py` is a
working reference implementation of §5.3 and of §11's second mechanical check. Eight
of fifteen estate repositories have yet to declare (§14). If it is useful as a
pattern to point them at, it is offered — as the delegation machinery was.