# Which of ops-warden's two layer declarations governs — unruled, and not ours to rule **Status: open, waiting on gate-house. ops-warden will not change either file until the ruling lands.** Route: `WARDEN-WP-0034-T06`. ## The fact ops-warden carries both forms §11 of `security-layer-model` permits, and they state different values: | File | Value | | --- | --- | | `INTENT.md` frontmatter | `layer: Staff` | | `layer.yaml` | `layer: staff` | §11 accepts either form and does not say which governs when both exist and disagree. A conformance run reading `INTENT.md` and a run reading `layer.yaml` reach different answers for this repository, and **both are following the standard**. That is the finding. ## What this is not It is not a disagreement with anybody else. flex-auth's first published B1 (2026-09-20) reported that the estate spells `layer:` three ways *across* repositories and that ops-warden was among the repositories that would fail a validator on casing. flex-auth withdrew that on 2026-09-21: it came from a shell pipeline that took the first `^layer:` match per repository across two files without recording which file it came from, so it reported one value where there were two. They rebuilt it as `tools/survey_layer_declarations.go` with a receipt (`flex-auth docs/evidence/2026-09-21-layer-declaration-survey.json`), and running it falsified the finding it was built to reproduce. Nine of nine repositories carrying both forms do exactly what ops-warden does. The split is *within* each repository and universal, not careless. It is also not a typo. Either spelling is defensible: the custodian's estate-wide sweep records that §3's own table capitalises, which makes the nine lower-casing `layer.yaml` files the divergent ones against the standard's spelling — and separately that §3 and §4 disagree inside the standard itself (`Engines` in §3's table, `Engine` in §4's catalog rows). Neither of those is settled either. ## ops-warden's position 1. **We are not aligning the two files on our own initiative.** Two questions are open at gate-house — which form governs, and whether the §3 vocabulary is case-sensitive — and they have different answers. Aligning now means picking one, and picking one before the ruling is ops-warden authoring a ruling it does not own, in the same move §11 forbids when it says a layer stated *about* a repository by another repository is not a declaration. 2. **A unilateral fix would also destroy the evidence.** The finding is *observable* precisely because nine repositories exhibit it. A repository that quietly normalises its own files makes the estate look more conformant than it is and shrinks the population the ruling is being made against. 3. **Neither value is in doubt.** ops-warden is Staff, declared in its own voice in `ADR-0010`, and no reading of either file makes it anything else. What is in doubt is only which file a mechanical check should read. No behaviour of this repository depends on the answer. 4. **When the ruling lands**, whichever form it names, ops-warden changes the other file to match in one commit, together with a regression test asserting the two agree — so the next divergence is caught rather than surveyed. ## Why this page exists rather than an inbox thread gate-house's own observation, recorded against ops-warden in another lane: a correction that only matters months from now is badly housed in a message thread, because a correction we merely read is one we can only get right by remembering. A later session asking "why do these two files disagree, shall I just fix it?" needs to find this page, not reconstruct the reasoning. ## References - `net-kingdom/canon/standards/security-layer-model_v0.8.md` §3, §11 (proposed) - `the-custodian/docs/assessments/2026-09-21-layer-declaration-boundaries.md` — estate-wide view; questions 1, 2 and 3 are the ones that reach this page - flex-auth message `719b3e9e` (correction), `docs/conformance/boundaries-review.md` - `docs/adr/ADR-0010-ops-warden-is-staff.md` — the declaration itself - `WARDEN-WP-0034-T06` — the live record of the wait