diff --git a/README.md b/README.md index 29fdbcf..40a22e3 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,7 @@ The dynamic, self-optimizing security platform is the long-term direction in ## Orientation - [SCOPE.md](SCOPE.md) — what this repo owns, current state, and when it is relevant -- [Security layer model](canon/standards/security-layer-model_v0.5.md) — how the +- [Security layer model](canon/standards/security-layer-model_v0.6.md) — how the security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each layer may own - [Security scenario composition](canon/standards/security-scenario-composition_v0.1.md) diff --git a/canon/standards/security-layer-model_v0.5.md b/canon/standards/security-layer-model_v0.5.md index 8e12dfc..9ee0867 100644 --- a/canon/standards/security-layer-model_v0.5.md +++ b/canon/standards/security-layer-model_v0.5.md @@ -3,7 +3,7 @@ id: netkingdom-security-layer-model-v0.5 type: standard title: "NetKingdom Security Layer Model v0.5" domain: netkingdom -status: proposed +status: superseded version: "0.5" supersedes: canon/standards/security-layer-model_v0.4.md owner: gate-house @@ -14,6 +14,7 @@ last_reviewed: "2026-08-28" review_interval: 3m source_revision: "gate-house@516ed4e" standard_token: security-layer-model_v0.5 +superseded_by: canon/standards/security-layer-model_v0.6.md assented_by: - "flex-auth FLEX-DEC-2026-001" - "kings-guard KG-DEC-2026-001" @@ -32,6 +33,11 @@ related: # NetKingdom Security Layer Model v0.5 +> **Superseded 2026-08-29 by [v0.6](security-layer-model_v0.6.md)**, after an +> independent assessment against industry practice found the Engine layer +> untyped, the enforcement point unnamed, containment marked pending against the +> wrong repository, and no temporal law behind the single decision point. + ## 1. Purpose This standard states how NetKingdom's IT-security estate is layered, and what diff --git a/canon/standards/security-layer-model_v0.6.md b/canon/standards/security-layer-model_v0.6.md new file mode 100644 index 0000000..b9ef5fa --- /dev/null +++ b/canon/standards/security-layer-model_v0.6.md @@ -0,0 +1,1085 @@ +--- +id: netkingdom-security-layer-model-v0.6 +type: standard +title: "NetKingdom Security Layer Model v0.6" +domain: netkingdom +status: proposed +version: "0.6" +supersedes: canon/standards/security-layer-model_v0.5.md +owner: gate-house +publication_owner: net-kingdom +created: "2026-08-28" +updated: "2026-08-28" +last_reviewed: "2026-08-28" +review_interval: 3m +source_revision: "gate-house@516ed4e" +standard_token: security-layer-model_v0.6 +assented_by: + - "flex-auth FLEX-DEC-2026-001" + - "kings-guard KG-DEC-2026-001" + - "ops-warden ADR-0010" + - "audit-core AUDIT-IN-0001, and v0.4 review with three findings" + - "flex-auth FLEX-DEC-2026-002 (v0.4, §9.3 contested)" + - "kings-guard v0.4 review, four findings" + - "ops-warden 2026-08-29 v0.4 review, three findings" +related: + - canon/standards/security-zones_v0.1.md + - canon/standards/tenancy-posture_v0.1.md + - canon/standards/credential-management_v0.2.md + - gate-house/decisions/decisions.md + - net-kingdom/history/2026-08-29-layering-standard-assessment.md + - gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md +--- + +# NetKingdom Security Layer Model v0.6 + +## 1. Purpose + +This standard states how NetKingdom's IT-security estate is layered, and what +each layer may and may not do. It answers one question: + +> **Given a repository, which layer is it in, and what does that permit it to +> own?** + +The layers are distinguished by **determinism** and by **the kind of artifact +the layer produces**, not by technical tier, deployment topology, or team. + +It is not an org chart, not a network model, not a deployment topology, and not +a dependency graph. It does not assign work, and it does not replace any +repository's boundary contract; it constrains what such a contract may claim. + +**What changed in v0.6.** An independent assessment against industry practice +(`net-kingdom/history/2026-08-29-layering-standard-assessment.md`) found the model +sound as a layering constitution and incomplete as a *self-healing* one: cognition, +authority, and execution are specified, but the two verbs that close a healing +loop — observe in production and actuate through a deterministic surface — are +pending, and one is unstaffed. It also found the Engine layer untyped, so that +"we need an engine for X" drifts toward "X now decides", and the enforcement +point unnamed. + +v0.6 types the engines (§3.3), names the enforcement point (§6.4), replaces the +containment assignment with an actuation surface held at zero (§9.2), separates +human and agent principals inside Staff (§3.4), puts time into the model (§9.7), +requires the Taxonomy artifacts that make §6.2 compileable rather than +reviewable (§17), and composes the sibling standards it had only cited (§18). +Section numbers below §14 are unchanged: the estate cites them. + +**What changed in v0.5.** All four reviewing repositories returned findings on +v0.4, and one contested a rule. §9.3 was wrong: it collapsed *engine reachable +but degraded* with *engine not reachable at all*, and the second case has no +evaluator in the path to express anything. §9.1 collapsed *no route exists* with +*route exists under a declared gap*, which would have forced a false "pending" +onto a production capability. §11 claimed mechanical checkability for a rule +that cannot be checked in prose. §13 filed two opposite conformance states in one +table and recorded proposed owners as owners. §9.6 needed the load-bearing +distinction it implied but never drew. §15 records the change list. + +**What changed in v0.4.** `audit-core` assented to the approval evidence half +and corrected the rationale twice. v0.3 rested §9.4 on that repository's INTENT +principle 6, which is an aspiration; the shipped bound in its `docs/integrity.md` +is weaker and conditional. More consequentially, no append-only archive can prove +**omission at source** — a suppressed revocation leaves the chain intact — which +is now stated as an estate-wide doctrine constraint (§9.6) rather than left +implicit. `audit-core` was also referenced as an owner in v0.3 without appearing +in the §4 catalog at all; it is catalogued here, as an Engine, on its own +declaration. §15 records the change list. + +**What changed in v0.3.** Two engines were seeded to own concepts v0.2 recorded +as unowned: `approval-engine` takes the approval object that §13 left homeless, +and `maturity-engine` takes graded progression — closing a §9.1 defect in +gate-house's own catalog claim, which asserted conformance review with no engine +to act through. §15 records the change list. v0.3 is **proposed**: the two new +engines are seeded by owner direction and have no other side to assent yet, and +the evidence half of the approval split needs `audit-core`'s assent. + +**What changed in v0.2.** v0.1 was assented to by all three repositories whose +boundaries moved, and each returned a finding. v0.1 had one lane for a Staff +repository that legitimately touches Tooling — read-only diagnostics — which is +narrower than the estate as it actually stands, and a rule with no lane for a +real sanctioned case is satisfied by relabelling rather than by closing the gap. +v0.1 also catalogued a capability (§4, containment) that §5 forbade discharging, +and applied its reconstructability test to engines but not to the doctrine +gate-house feeds them. §15 records the full change list. + +## 2. Authority and conformance + +| Fact or rule | Authority | +| --- | --- | +| The layers, their definitions, and the rules between them | This standard, owned by gate-house | +| Which layer a given repository is in | This standard, §4 catalog | +| What a repository owns within its layer | That repository's `INTENT.md` and boundary contract | +| Whether a specific request is permitted | `access-engine` — never this standard | +| Whether a Tooling contact is sanctioned | The declaring repository, under the shapes in §5, reviewable by gate-house | +| Security doctrine and invariants | gate-house | +| Publication | net-kingdom canon | +| Whether an invariant is *watched in practice* | the observing repository's own report — never this standard, and never §12's diagram | + +A repository conforms when its `INTENT.md` declares its layer, its claims fall +within that layer's permissions (§3), and its Tooling contacts take one of the +sanctioned shapes in §5 or are declared as gaps under §5.3. + +**No estate argument may cite observation that has not happened.** §12 lists +`kings-guard` against the loop's fourth step, and that repository has reported +that it has never observed a real event. Until it reports otherwise, no +assessment, review, or decision in this estate may treat an invariant as being +watched in practice on the strength of the diagram. Lifted here from §12 so it +cannot be lost in a summary. + +## 3. The layers + +| Layer | Character | Produces | Deterministic | +| --- | --- | --- | --- | +| **Taxonomy** | cross-cutting language | terms, semantic contracts, standards | n/a — describes | +| **Tooling** | infrastructure and state | data structures, persistence | yes | +| **Engines** | interfaces for a modeled concept | APIs, contracts | yes | +| **Staff** | management, operations, change, controlling | specifications, decisions, workplans, tasks | **no** | + +### 3.1 Taxonomy + +Cross-cutting language. Taxonomy repositories define terms and semantic +contracts so the other layers interoperate without integration by +interpretation. They own no runtime position and no state any layer depends on. + +`info-tech-canon` holds ecosystem-wide semantic contracts. NetKingdom-specific +security architecture — including this standard — is net-kingdom canon's. + +### 3.2 Tooling + +Deterministic infrastructure: data structures, persistence, and the consistent, +performant, scalable keeping of state. Much of it is third-party. + +### 3.3 Engines + +Deterministic APIs for a modeled concept — a user, a tenant, a zone, a secret, +an access rule. An engine's defining property is that **the same authoritative +input state yields the same result**. Engines are where the estate's +deterministic guarantees live, and therefore where every enforcement boundary +MUST sit. + +A repository whose core function is inference or judgment fails this test by +construction and is Staff, however much of its work happens at runtime. + +**Engines are typed.** "Engine" is one layer but four roles, and collapsing them +hides different failure modes. Every §4 Engine row carries a role: + +| Role | Meaning | Outage means | +| --- | --- | --- | +| **PDP** | renders the authorization decision — `access-engine`, and only it (§6) | consumer residue (§9.3) | +| **PIP** | supplies facts a decision consumes as claims — user, tenant, zone, approval, maturity | input degradation, engine's own fallback (§9.3) | +| **Evidence** | records what happened and proves integrity of what it holds — `audit-core` | MUST NOT block the operation being recorded (§9.4) | +| **Lifecycle** | a deterministic API over Tooling it owns — `secrets-engine` | the owning engine's failure semantics | + +The roles are why *"we need an engine for X"* does not mean *"X now decides"*. +A new engine is a PIP unless this standard is amended to say otherwise, and §6 +means it can never be a second PDP. + +The industry vocabulary is deliberately mirrored here — PDP, PIP, PEP as in +NIST ZTA and XACML — because it is how the estate talks to the outside and how a +PEP is stopped from quietly becoming a PDP. The determinism cut in §3 stays +primary where the two disagree. + +### 3.4 Staff + +Interactive and non-deterministic. Staff is the management layer: operations, +change, innovation, and controlling. It works through agentic capability — +assistants and autonomous agents — and its artifacts are specifications, +decisions, workplans, and tasks. + +Staff repositories MUST NOT hold state that another layer depends on at +runtime, and MUST NOT render or cache any decision an Engine is responsible for. + +Acting at runtime does not make a repository an Engine. Being agentic makes it +Staff, and §5 governs how it acts. + +## 4. Layer catalog + +| Repository | Layer | Role | Owns | +| --- | --- | --- | --- | +| `info-tech-canon` | Taxonomy | — | ecosystem-wide semantic contracts and terminology | +| `net-kingdom` | Taxonomy | — | NetKingdom standards of record; publication | +| `key-cape` | Tooling | — | packaged identity tooling; IAM profile; authentication | +| `OpenBao` | Tooling | — | secret storage, leases, PKI, dynamic secret engines | +| `user-engine` | Engine | PIP | users, accounts, memberships | +| `tenant-engine` | Engine | PIP | tenant-as-an-entity facts | +| `zone-engine` | Engine | PIP | zone identity and membership — offline reference conformance per its 2026-08-23 disposition | +| `secrets-engine` | Engine | Lifecycle | credential abstraction, custody, lifecycle | +| `audit-core` | Engine | Evidence | audit event custody, retention, integrity verification, export — explicitly not a decision point (§9.6) | +| `access-engine` | Engine | **PDP** | **the policy decision** — the only decision point (§6) | +| `approval-engine` | Engine | PIP | the approval object — durable, authenticated, consumable, atomically supersedable (§9.4) | +| `maturity-engine` | Engine | PIP | graded progression against declared criteria and evidence; the gap register; capability readiness (§9.5) | +| `gate-house` | Staff | — | security doctrine, authority context, curriculum; **conformance review — through `maturity-engine` (§9.5)** | +| `ops-mason` | Staff | PEP-shaped | building and tearing down access routes and perimeters | +| `ops-warden` | Staff | PEP-shaped | operational access lanes, stewardship, runbooks; SSH certificate issuance — **declared-gap** (§9.1, §13) | +| `kings-guard` | Staff | — | adaptive defence and judgment; observation of Staff-reachable sources — identity and secret observation **pending**; **proposes** containment, which it does not own (§9.2) | +| `whitehat-security` | Staff | — | offensive validation | + +An **actuation surface** — reduce authority, require step-up, isolate a workload +— is catalogued nowhere because it does not exist. See §9.2: it is an Engine +concept held at zero, not a Staff capability. + +`access-engine` is the ruled name for the repository currently called +`flex-auth`; both denote the same authority until the governed rename completes. +Execution conditions for that rename are recorded in its migration decision, not +here. + +## 5. The binding rule + +> **Staff never touches Tooling directly. It acts only through Engine APIs.** + +A Staff repository MUST NOT hold a direct client for a Tooling-layer system — +no direct database connection, no direct OpenBao client, no direct cluster +mutation — outside the shapes below. This is the architectural form of *no +privilege from cognition*, and it is deliberately mechanically checkable. + +**Scope.** "Tooling-layer system" means a system catalogued as Tooling in §4. +Infrastructure the estate runs but has not catalogued — the State Hub, +`llm-connect`, and similar — is outside this rule, because a rule that silently +covered them would put every Staff repository in undeclared violation on +adoption day: they all write progress events. Such clients SHOULD be recorded +in the repository's declaration as non-Tooling for completeness of the check, +and the way to bring one under §5 is to catalogue it in §4, deliberately. + +Raised by `ops-warden`, which held clients for both and declined to resolve the +scope question on gate-house's behalf. + +**The carve-out sunsets.** It is a pressure valve, and a valve left open becomes +a second persistence plane under the Staff layer — which §3.4 forbids in spirit. +Three rules bound it: every non-Tooling client MUST be listed in the +repository's declaration; an uncatalogued store that another layer **reads** +MUST, within two review intervals, either be catalogued as Tooling in §4 or be +declared a gap under §5.3; and a Staff-owned event bus or memory store MUST NOT +become the estate's de facto state plane. Today's instances are the State Hub +and `llm-connect`; tomorrow's are agent memory, tool-call traces, and prompt +caches (§3.4). + +Three shapes are sanctioned. Everything else is a violation. + +### 5.1 Read-only diagnostic observation + +A Staff repository MAY read Tooling state for diagnostics where the owning +engine exposes no equivalent. It MUST be declared in the repository's +`INTENT.md`. It grants no write, and it is an engine gap to close, not a +standing arrangement. + +### 5.2 Conduit + +A Staff repository MAY run the **owner's** tool under the **caller's** identity, +supplying no authority of its own. The test is the supplied-authority property: +the conduit MUST NOT present its own credential, MUST NOT widen what the caller +could already do, and MUST be reconstructable as the caller's action in audit. + +A conduit that presents its own token is not a conduit; it is §5.3 or a +violation. This shape MUST be declared, and the no-authority property SHOULD be +covered by a test. + +The reconstructability requirement is an audit-dependent claim and is therefore +bounded by §9.6: the archive shows the conduit actions it received, not that it +received all of them. + +### 5.3 Declared engine gap + +Where a Staff repository must contact Tooling directly and no engine exposes the +capability, it MUST declare the contact rather than take an exemption. A +declared gap carries, machine-readably: + +| Field | Meaning | +| --- | --- | +| `capability` | what the contact does | +| `intended_owner` | the engine that should own it | +| `blocked_on` | why it cannot move today | +| `review` | a date, not "when convenient" | + +A declared gap is **tracked non-conformance**, not conformance. It does not +expire on its own and it is not a licence to add more. It exists because a rule +offering no lane for a real sanctioned case gets satisfied by relabelling rather +than by closing the gap — and a tracked gap is visible, whereas a relabelled one +is not. + +Prior art: `ops-warden` runs equivalent machinery for delegated lanes (27 +catalog entries carrying `delegation:`, queryable via `warden route gaps`), and +has offered it as reusable. + +**No fourth "operator of third-party Tooling" shape.** It has been proposed, on +the argument that someone must operate `OpenBao` and every operational necessity +otherwise looks like a gap. Declined: §5.3 already sanctions the operation while +keeping it visible, and a clean "operator" shape would convert a tracked gap +into a permanent allowance — the relabelling failure this standard exists to +prevent. A permanent operational necessity is a declared gap whose review +interval keeps returning, which is the correct amount of friction. If the review +becomes ceremonial, that is an argument for closing the gap, not for renaming +it. + +## 6. One decision point + +`access-engine` is the only policy decision point in NetKingdom. No other +repository, in any layer, may render or cache authorization decisions. + +First ruled in `zone-engine/INTENT.md` §5 — *"flex-auth is the policy decision +point. It stays the only one."* The failure mode, from the same source: *"It +becomes a second decision point… it would arrive as a small convenience."* + +### 6.1 Compiled data that determines an outcome is still deciding + +A registry, cache, or schema that resolves a result before the engine runs has +decided early. Provenance MUST remain reconstructable from the engine's decision +record. + +### 6.2 Doctrine reaches the decision as an input, or it is not applied + +This rule binds gate-house on the same terms. **An authority ceiling, mandate +constraint, or operating-mode restriction that determines an outcome MUST reach +the decision either as an input claim on the request or as a rule in the +versioned policy package**, so that its application is reconstructable from the +decision record. + +Doctrine that influences outcomes by any other route is a second decision point +wearing an author's hat. This is not a limit on gate-house's authorship; it is +what keeps that authorship auditable at decision time. + +### 6.3 No Staff repository may host a decision point + +A deterministic authority boundary inside a non-deterministic layer contradicts +the invariant the estate is built on. gate-house was re-cut on this ground. + +### 6.4 The enforcement point + +The standard has been precise about the decision and silent about the gate. A +decision that nothing refuses to proceed without is advice. + +A **PEP** is any runtime that causes a protected side effect. It is a *shape*, +not a repository: `ops-warden` issuing a certificate, `ops-mason` opening a +route, and any protected system acting on a verdict are all PEP-shaped. Being +PEP-shaped does not move a repository out of its layer. + +Four obligations, and they are normative: + +1. **No side effect without a decision record.** A PEP MUST NOT perform the + protected action unless it holds a decision from `access-engine` identifying + the request it was rendered for. +2. **No local recaching of the verdict.** A stored verdict replayed for a later + request is a second decision point deciding early (§6.1). Caching an *input + claim* under its own freshness rules is permitted; caching the *answer* is + not. +3. **A declared unreachable-engine stance** (§9.3): total, per zone or + equivalent scope, no implicit default, no per-call discretion, published + rather than held in code comments. `ops-warden` `ADR-0009` is the reference + shape. +4. **Reconstructability**, bounded by §9.6. + +Every PEP-shaped consumer MUST publish its stance map, and those maps MUST be +inventoried — in `maturity-engine` once it exists, in §13 until then. §9.3 is +otherwise a ruling with no register behind it, and *"`z0`–`z2` and unknown fail +open"* becomes the estate's real policy without anyone having compiled it into a +versioned package. + +Raised by the 2026-08-29 independent assessment: NIST ZTA splits decide from +enforce, and this standard had only the first half. + +## 7. Relationship to the Active Secrets Management Canon + +```text +Staff interactive, non-deterministic ≈ Cognitive Plane +Engines deterministic APIs ≈ Authority Plane +Tooling deterministic state ≈ Execution Plane +Taxonomy cross-cutting language +``` + +*Cognition proposes. Authority disposes. Infrastructure executes.* is therefore +NetKingdom's layering rule, not only its security maxim. §5 and §6 are that +principle applied to repositories rather than to requests. + +## 8. Vocabulary demarcations + +| Term | Belongs to | Not | +| --- | --- | --- | +| **access lane** | ops-warden, ops-mason (Staff) — how a worker reaches a host | the decision whether they may | +| **access rule** | access-engine (Engine) — whether an actor may act | the route by which they arrive | +| **control plane** | Engine layer | a Staff repository's self-description | +| **doctrine** | gate-house | a lane owner's runbook | +| **runbook** | the Staff repository stewarding the lane | a substitute for doctrine | +| **posture** | kings-guard publishes; gate-house defines its authority meaning; access-engine renders it | a privilege source | + +Posture carries an asymmetry that MUST hold: adaptive systems may reduce +authority, require step-up, or request containment. They MUST NOT +probabilistically manufacture additional authority. + +The asymmetry is what bounds the damage when observation is incomplete (§9.6): +suppressed evidence can only prevent a tightening that should have happened, never +engineer a loosening. That is an argument for keeping it absolute rather than +situational. + +## 9. Capability assignment + +### 9.1 The catalog may not assign what the rules forbid discharging + +A Staff repository MUST NOT be catalogued in §4 as owning a capability it cannot +discharge under these rules. Two marks distinguish the two ways that happens, and +they are not interchangeable: + +| Mark | Meaning | +| --- | --- | +| **pending** | No route exists. No engine exposes the capability, the repository makes no Tooling contact, and the capability is **zero** — not degraded. | +| **declared-gap** | A route exists through a §5.3 declared gap. The capability **works** and is tracked, with an intended owner and a review date in §13. | + +v0.4 had only `pending`, which forced a false choice. `ops-warden` holds +production-verified SSH certificate issuance through a declared OpenBao contact; +marking it `pending` would have told readers the repository does not do the one +thing it demonstrably does daily, while leaving it unmarked left §4 disagreeing +with §13. Neither is acceptable, and the defect was in this section rather than +in the catalog. + +`pending` was written for `kings-guard`'s containment — no route, capability +zero — and remains correct there. `declared-gap` is the case §5.3 was added to +sanction. Raised by `ops-warden`. + +Both marks apply per capability, not per repository. A repository may hold one +capability outright, another under a declared gap, and a third pending. + +### 9.2 Actuation does not exist, and containment is not Staff's to own + +Self-healing needs four verbs: observe, evaluate, decide, actuate. Observation is +`kings-guard` and is unstaffed (§12). Evaluation is `maturity-engine` and is +seeded. Decision is `access-engine` and works. **Actuation has no surface at +all**, and a model with no actuation surface describes a diagnosis machine +rather than a healing one. + +v0.5 marked containment `pending` against `kings-guard`, which was the right +mark on the wrong repository. Containment is not a Staff capability that happens +to lack a route: **reduce authority, require step-up, isolate a workload** are +authority-changing operations, and under §6 an authority-changing operation is +rendered by an Engine and enforced by a PEP (§6.4). A Staff repository proposes +containment; it never performs it. + +The **actuation surface** is therefore an Engine concept — likely a small +surface on `access-engine` together with runtime PEPs — carrying the same +reconstructability rules as any other decision: a containment action is a +decision record, not a side channel. + +It is **unowned and held at zero**. `access-engine` is recorded in §13 as a +*proposed* owner and has explicitly not reviewed it (`FLEX-DEC-2026-002`). No +repository may be catalogued as owning containment until the surface exists — +§9.1 applied to the estate's most operationally tempting gap, and the standard's +own medicine. + +Until then `kings-guard` proposes and judges, its containment claim stays at +zero rather than degraded, and no argument may assume the estate can contain +anything automatically. + +### 9.3 Degraded mode: two failure cases, two owners + +v0.4 collapsed two failures into one rule. They have different owners because +one has an evaluator in the path and the other does not. + +**Input degradation — the engine's.** Where `access-engine` is reachable but +cannot reach its own inputs, the deterministic *fail to reduced authority* +default belongs to the engine. This keeps the decision at the decision point and +keeps the fallback deterministic, which a Staff-layer fallback could never be. + +**Engine unreachable — necessarily the consumer's.** Where `access-engine` is +not reachable at all, it applies nothing, because it is not running. Whatever +happens next is the consumer's behaviour by construction: fail-open is not +expressible by a policy decision point, since there is no evaluator in the path +to express it. A standard that assigns this to the engine assigns it to nobody. + +The consumer's residue is bounded rather than free. A protected system MUST +declare its unreachable-engine stance ahead of time, per zone or equivalent +scope, and that stance MUST be auditable and total — no implicit default, no +per-call discretion. `ops-warden` `ADR-0009` already satisfies this: a total +per-zone map, open for `z0`–`z2` and unknown, closed for `z3-critical`, +replacing the global `policy.enabled` / `policy.fail_closed` switches it +superseded. + +**Unchanged: engine-unavailable is not grounds for a Staff break-glass path.** +The distinction is whether an engine is there to ask. A bypass around a +*reachable* engine is a second decision point, and an incident is when an +attacker most wants that shortcut. A consumer choosing its declared behaviour +when there is no engine to ask is not a bypass; it is the only thing left. + +Contested by `flex-auth` (`FLEX-DEC-2026-002`), which has held since 2026-08-19 +that fail-open is not expressible by a PDP, and which noted v0.4 collided with +shipped behaviour in a repository that had assented to this standard. + +### 9.4 Approvals are an engine concept, not a Staff or audit concern + +The approval object — durable, authenticated entries, distinct-approver +counting, atomic supersession, single consumption, revocation without holder +cooperation — is owned by `approval-engine`. + +It is not Staff's: §3.4 forbids Staff holding state another layer depends on at +runtime. It is not the decision point's: an evaluator that owns the object it +evaluates is self-dealing. It is not the audit fabric's: an approval needs +mutable, in-path, current-state semantics, and an append-only archive is built +for the opposite property. + +`access-engine` consumes approvals as **input claims** under §6.2 and never +mutates them. Every issuance, use, supersession, and revocation is emitted to +`audit-core`: the operative state and the evidence record are different +artifacts with different owners. + +The evidence guarantee is bounded, and the bound is `audit-core`'s +`docs/integrity.md`, not its INTENT principle 6. An in-database hash chain +detects a rewritten payload only if the attacker does not also recompute the +suffix — which a database owner can. Detection against that class requires the +external chain-head attestation, and even with it the store is not WORM, object +lock, or archival custody. `tamper_evidence` is therefore conditional on live +preconditions, not a property of the store at rest, and approval events receive +exactly the guarantee every other source receives. + +**Emission atomicity is `approval-engine`'s obligation.** An approval MUST NOT be +issued, consumed, superseded, or revoked without the corresponding event being +durably queued in the same transaction. + +**The queue MUST be local.** The durable queue MUST live in `approval-engine`'s +own transactional store, and **no synchronous dependency on `audit-core` may sit +inside the state-change transaction**. With a genuine local outbox, fail-closed +triggers only when `approval-engine`'s own store is unavailable — where the +change could not have been recorded anyway — and an `audit-core` outage does not +block a revocation. Satisfying the requirement by emitting synchronously to +`audit-core` inside the transaction is also atomic, and turns an audit outage +into an inability to revoke: the operation least tolerable to block during an +incident, and the same coupling this section rejects for reads. Raised by +`audit-core`. +`audit-core` reports what it received and does not imply it is everything that +happened; without atomic emission the evidence half is silently incomplete and +nothing detects the gap. This is a condition of `audit-core`'s assent +(`AUDIT-IN-0001`) and belongs in `approval-engine`'s contract before the evidence +half is treated as load-bearing. + +`audit-core` MUST NOT expose an approval-validity query. Records, yes; a verdict +on whether an approval is still valid, never — a consumer branching on that +answer would route an authorization decision through the audit fabric, which is +what this section exists to prevent. Callers needing current state ask +`approval-engine`. + +### 9.5 Graded progression is an engine concept + +Maturity — how far a subject has progressed against declared criteria and +submitted evidence — is owned by `maturity-engine`. Given the same criteria and +the same evidence it MUST return the same level; that determinism is what makes +it an Engine rather than an opinion. + +The division with Staff: **gate-house judges and proposes; maturity-engine +computes and remembers.** Interpretation is inference and stays Staff. A +criterion that cannot be evaluated by rule is not yet a criterion. + +This closes a defect in v0.2's own catalog: `gate-house` was assigned +conformance review with no engine to act through, which is exactly the §9.1 +problem raised against the containment claim. Staff acts only through Engine +APIs, including gate-house. + +**A maturity level MUST NOT be compiled into registry content.** Until +`access-engine`'s decision provenance carries a registry-snapshot digest — a gap +it self-declared in §13 — a level reaching a decision through the registry is not +reconstructable from the decision record. Levels arrive as request claims or as +versioned policy rules. Same constraint, and same reason, as zone stance. + +**A maturity level MUST NOT gate a decision directly.** Under §6.1, compiled +data that determines an outcome is still deciding. If a level determines whether +an action is permitted, it MUST reach `access-engine` as an input claim or a +versioned policy rule under §6.2, never by a consumer branching on a fetched +level. + +Approvals and maturity are deliberate opposites — a closed binary state machine +against an open graded ladder — and neither engine may drift toward the other. + +### 9.6 Evidence proves alteration and truncation, not omission at source + +An append-only archive with a verified hash chain proves that records were not +**altered or truncated after arrival**. It cannot prove that a record was never +sent. Against a compromised or buggy source, a suppressed event leaves the chain +perfectly intact and verification reports intact. + +This bound is estate-wide. Statements of the form *"the audit record proves it +happened"* are unsound; the sound form is *"the archive proves the records it +holds were not altered or truncated after arrival"*. Its mirror is equally +unsound: **absence of a record is not evidence of non-occurrence**, and no +control may read it as such. + +**Load-bearing versus attributive evidence.** The atomicity obligation attaches +to the first, not to both: + +| Kind | Test | Obligation | +| --- | --- | --- | +| **Load-bearing** | a control's soundness depends on the event being present or absent — an approval revocation, a containment action, a denial | emission MUST be atomic with the state change (§9.4) | +| **Attributive** | the event supports forensic reconstruction and attribution, and no control branches on its presence | atomicity SHOULD be sought; where it is deliberately traded away, the trade MUST be declared and completeness MUST NOT be claimed | + +Where a repository deliberately makes emission non-atomic — `ops-warden`'s +`# audit must not block signing` is the estate's live example, chosen so that an +audit-store failure cannot remove production host access — the trade is +legitimate for attributive evidence, MUST be declared where the trail is +documented, and MUST NOT be described in terms that imply completeness. The +availability argument is real in both directions: making it atomic gives the +estate's operational access lane a new dependency on its own evidence store. + +**Consequence for adaptive systems.** Suppression does not degrade observation +neutrally, it biases it optimistic, and silently: an event never emitted is never +evaluated, so no finding is raised and the last posture stands. A confidence +score computed from the richness of the record in hand cannot express doubt about +the completeness of the stream — a well-formed observation from a 90%-suppressed +stream scores high. That is this section's failure reproduced one layer up, in +the consumer. + +Two things follow. + +1. **The §8 asymmetry bounds the damage, and this is its clearest payoff.** + Because an adaptive system may only reduce authority and never manufacture it, + suppression can only prevent a tightening that should have happened. It cannot + be used to engineer a loosening. The harm is a missed reduction, not an + invented privilege — which is an argument for keeping the asymmetry absolute. +2. **Silence is a signal.** A source SHOULD declare an expected emission cadence, + and a drop below it SHOULD become a finding in its own right — the stream + observed, not only its contents. This converts the blind spot into something + detectable without any Tooling contact and without any engine gap, because the + source publishes its own stream. + +Raised by `audit-core` against its own principle; extended by `kings-guard` from +its own evaluator and confidence model. + +### 9.7 Decisions have a lifetime + +A single decision point deciding on stale claims is a single decision point +deciding wrongly. The model has had no temporal law, and the approval race in +§16 was its first symptom. + +1. **Every allow has an explicit lifetime** — a TTL, or a binding to a session + or obligation that ends. An allow with no stated end is a standing grant, and + standing grants are what this estate exists to remove. +2. **Revocation and supersession have a visibility deadline.** Each PDP and PEP + MUST state how quickly a revocation becomes effective at its own boundary. + "Eventually" is not a stance; an unstated deadline is an unbounded replay + window. +3. **Consumption is a state change, never an inference.** An approval is + consumed by a mutation in `approval-engine` (§9.4). It MUST NOT be inferred + from the existence of a decision record — the decision precedes the action + and the action precedes consumption, so a decision record proves an intent to + act, not an act. +4. **Three failure modes are named, and each needs an owner**: an allow rendered + then never consumed; a double consumption by racing callers; consumption + after the authorized action has already failed. Neither engine closes these + alone. Recorded in §16 and `GH-WP-0002-T06`. + +### 9.8 Partition is not one-dimensional + +§9.3 handles *engine unreachable*. A real estate spends most of its incident +time in the band between reachable and gone: partial PIP reachability, clock +skew across a decision and its enforcement, and two consumers with different +declared stances seeing different worlds at the same moment. + +Two rules hold today, and the rest is open (§16). A PEP MUST resolve its own +stance from its declared map without consulting another consumer — divergent +views are expected and are not a coordination problem to be solved at enforcement +time. And where clock skew could extend a lifetime under §9.7, the shorter +reading governs. + +## 10. Changing layer + +A repository's layer is not permanent. `zone-engine` changed layer in practice +when its runtime hypothesis was falsified. + +A layer change MUST be recorded as a decision, MUST update the repository's +`INTENT.md`, and MUST obtain assent from the repositories whose boundaries move. +A repository MUST NOT acquire a new layer's permissions by gradual practice. + +"No gradual practice" needs a check rather than a sentence. A layer change MUST +carry six artifacts, written from the `zone-engine` case that the procedure +should have been derived from in the first place: + +| Artifact | Why | +| --- | --- | +| before/after `INTENT.md` | the declaration is the conformance surface (§11) | +| client inventory | what the repository holds against Tooling, before and after | +| gap inventory | which §5.3 gaps close, open, or transfer | +| assent list | every repository whose boundary moves | +| state-migration decision | what happens to live state and to consumers reading it | +| permission freeze | no new permissions of the target layer are exercised until the cut completes | + +The freeze is the one that makes the rule checkable: a repository mid-change +holds its old permissions, not the union of both. + +## 11. Conformance + +Conformance has four states, and the distinction between the last two is the +point: + +| State | Meaning | +| --- | --- | +| **Conforming** | no Tooling contact, or only §5.1/§5.2 shapes, declared | +| **Blocked-clean** | the capability does not exist because no engine exposes it, and the repository makes **no** Tooling contact — §9.1 `pending`, and not a non-conformance | +| **Declared gap** | a §5.3 contact with owner, blocker, and review date — tracked non-conformance | +| **Undeclared violation** | anything else — a finding | + +**Blocked-clean is not a lesser state than conforming.** A repository that +declined a break-glass path and left a capability at zero has complied at cost; +a repository that quietly opened a direct client and declared nothing has not. +Any downstream scoring — `maturity-engine` included (§9.5) — MUST NOT rank the +first below the second. Raised by `kings-guard`, whose three gaps are all of +this kind and which would otherwise have been graded down three times for +having taken the standard seriously. + +**Who must declare.** A repository the estate authors declares its layer in its +own `INTENT.md`. For a component the estate catalogues but does not author — +third-party or vendored, such as `OpenBao` — the §4 catalog row **is** the +declaration, and no `INTENT.md` obligation attaches. A rule that assigns an +obligation the holder cannot discharge is the §9.1 defect applied to conformance +rather than capability. + +A layer stated *about* a repository by another repository is not a declaration. +Review notes, catalog rows, and correspondence record an intent to adopt; only +the repository's own file conforms. + +**Declaration form.** Because prose cannot distinguish a declaration from a +transcribed review, a declaration MUST carry a machine-readable form: a `layer:` +key in the `INTENT.md` frontmatter, or an equivalent declaration file. Without +it this section asserts a property it cannot deliver — the defect this standard +has now corrected three times elsewhere. `ops-warden` has implemented a reference +form (`layer.yaml`, a conformance script, and a test covering the §5.2 +no-authority property) and offered it to the repositories that have yet to +declare. Raised by `audit-core`, which noted that `flex-auth`'s conforming +declaration is legible as one only by following its decision trail. + +Mechanically checkable: + +- every estate-authored repository in §4 carries a machine-readable layer + declaration; +- every direct Tooling client in a Staff repository maps to a declared §5.1, + §5.2, or §5.3 entry, and non-Tooling clients are recorded so the check is + total; +- no repository other than `access-engine` exposes an authorization decision + surface; +- no §4 capability is catalogued without an engine surface, a `pending` mark, or + a `declared-gap` mark. + +Requires review: whether claims stay inside layer permissions; whether compiled +or cached data has become an early decision (§6.1); whether doctrine is reaching +decisions as declared inputs (§6.2); whether the §8 vocabulary is used correctly. + +## 12. The conformance loop + +Doctrine no engine implements is fiction. The loop is normative, not +aspirational: + +```text +gate-house asserts an invariant + → the engines implement it, or declare a gap + → whitehat-security tries to break it + → kings-guard observes it in operation + → findings return to gate-house as doctrine change +``` + +A finding that a rule is unsatisfiable is a **success** of this loop, not a +failure of the reporting repository. Four of this standard's five versions exist +because a reviewing repository used it. + +**Step four is currently aspiration.** `kings-guard` has disclosed that it has +never observed anything in operation: the pilot is specified and scaffolded, every +input is a hand-built fixture, and no test has met a real event. Until it reports +otherwise, no argument in this estate may assume an invariant is being watched in +practice because §12 lists a repository against that step. + +## 13. Open gaps + +Two different things are recorded here, and they are opposite conformance states +(§11). A **declared contact** means the repository touches Tooling because no +engine exposes the capability. An **unowned capability** means no route exists +and the repository makes no contact at all. Reading them as one list would grade +restraint as though it were non-conformance. + +An `intended owner` is a **proposal to** the named repository, not an assignment +**onto** it. §2 keeps ownership in the repository's own `INTENT.md`, so the +register distinguishes proposed from assented. + +| Gap | State | Declared by | Owner | Owner status | +| --- | --- | --- | --- | --- | +| SSH-CA signing write (`VaultCA`, `bao kv put`) | declared-contact | ops-warden | secrets-engine | proposed | +| Authentication / assurance evidence | unowned-capability | kings-guard | identity layer + audit-core | **access-engine declined** | +| Secret-use evidence | unowned-capability | kings-guard | secrets-engine | proposed | +| Containment surface | unowned-capability | kings-guard | access-engine + runtime engines | proposed | +| Identity and secret observation | unowned-capability | kings-guard | as above | proposed | +| Registry-snapshot digest in decision provenance | declared-contact | flex-auth | flex-auth | self-declared | +| Approval storage and lifecycle | — | flex-auth | approval-engine | assigned (§9.4) | +| Approval evidence | — | gate-house | audit-core | **assented** (`AUDIT-IN-0001`) | +| Approval evidence custody stronger than the shipped bound — WORM, object lock, transparency log | unowned-capability | audit-core | — | unassigned | +| Emission atomicity for approval state changes | — | audit-core | approval-engine | assigned (§9.4) | +| Non-atomic audit emission on the SSH signing lane | declared-contact | ops-warden | ops-warden | self-declared, attributive (§9.6) | + +`access-engine` declined authentication and assurance evidence +(`FLEX-DEC-2026-002`): it consumes assurance claims as input and never redefines +them, so evidence of authentication belongs to the identity layer and +`audit-core`. It owns evidence of the decision, which it already emits. The +containment surface is recorded as proposed and remains `pending` under §9.2. + +Whether approvals warrant custody stronger than every other source is doctrine +work not yet done; until it is, approval evidence carries the same guarantee as +any other source and §9.6 bounds what may be claimed from it. + +**What is normative here, and what is a snapshot.** Three rules are part of this +standard and survive wherever the register lives: + +1. the two marks — `pending` and `declared-gap` (§9.1); +2. the owner-status rule — a proposed owner is not an assigned one (§2); +3. the scoring rule — `blocked-clean` MUST NOT rank below conforming (§11). + +**The table above is a snapshot, not statute.** It moves into `maturity-engine` +as soon as that engine can store state, and the `state` and owner-status columns +MUST survive the migration. A standard that is also a backlog keeps attracting +findings that belong in the register, and its review interval is far slower than +the register's real rate of change. + +## 14. Adoption + +Status is **proposed** — the frontmatter is authoritative, and v0.2 was the last +version to reach `accepted`. Four repositories have assented, each with a record, +and all four returned findings on the versions since: + +| Repository | Record | Outcome | +| --- | --- | --- | +| flex-auth | `FLEX-DEC-2026-001` | assent to all three items; one self-declared non-conformance; two rename conditions | +| kings-guard | `KG-DEC-2026-001` | assent; declined the offered §5 relaxation; raised §9.1 | +| ops-warden | `ADR-0010` | assent to all three; veto not exercised; offered the §5.3 amendment | +| audit-core | `AUDIT-IN-0001` | assent to the evidence half with conditions; corrected the rationale twice; raised §9.6 | + +Adoption for a repository means its `INTENT.md` declares its layer, its +ownership claims fall inside that layer, its Tooling contacts are declared under +§5, and any shared boundary has been assented to by the other side. + +**Adoption status as of 2026-08-29: seven of sixteen** estate-authored §4 +repositories have declared in their own voice — `gate-house`, `flex-auth`, +`kings-guard`, `ops-warden`, `audit-core`, `approval-engine`, `maturity-engine`. +The remaining nine — `info-tech-canon`, `net-kingdom`, `key-cape`, +`user-engine`, `tenant-engine`, `zone-engine`, `secrets-engine`, `ops-mason`, +`whitehat-security` — carry a layering review note authored by `gate-house` and +have not answered it. Those notes state a layer but do not constitute a +declaration, and this standard does not claim estate-wide adoption on their +basis. Declaration requests are open as intakes in each. + +## 15. Change log + +v0.1 → v0.2: + +1. **§5 restructured** into three sanctioned shapes. Added §5.2 conduit + (ops-warden's question, ruled) and §5.3 declared engine gap (ops-warden's + amendment, accepted). +2. **§6.2 added** — doctrine must reach the decision as an input claim or a + versioned policy rule (flex-auth's boundary drawn back, accepted). +3. **§9 added** — the catalog may not assign a capability the rules forbid + discharging; containment marked pending; degraded-mode fallback ruled into + the engine (kings-guard's finding). +4. **§11 restructured** — conformance now has three states, distinguishing a + tracked gap from an undeclared violation. +5. **§12 made normative**, with the explicit statement that an + unsatisfiability finding is a success of the loop. +6. **§13 added** — open gaps register, including the unowned approval storage + and lifecycle capability. +7. §4 catalog gained the pending mark and ops-warden's SSH certificate lane. + +v0.2 → v0.3: + +1. **§9.4 added** — approvals assigned to `approval-engine`, with the operative + state and the evidence record separated between it and `audit-core`. +2. **§9.5 added** — graded progression assigned to `maturity-engine`, closing + the §9.1 defect in gate-house's own conformance-review claim, and carrying + the guardrail that a level may never gate a decision directly. +3. §4 catalog gained both engines; gate-house's conformance-review claim now + names the engine it acts through. +4. §13 register updated: the approval hole is assigned, two new entries added. + +v0.5 → v0.6, from the independent assessment of 2026-08-29: + +1. **§3.3 types the engines** — PDP, PIP, Evidence, Lifecycle, with a role + column in §4. A new engine is a PIP unless this standard says otherwise, so + "we need an engine for X" cannot drift into "X now decides". +2. **§6.4 names the enforcement point** — a PEP shape with four obligations: no + side effect without a decision record, no local recaching of the verdict, a + declared unreachable-engine stance, reconstructability. The standard had the + decision and not the gate. +3. **§9.2 replaced** — containment was marked pending against the wrong + repository. Actuation is an Engine concept, unowned, held at zero; Staff + proposes containment and never performs it. +4. **§3.4 separates the two Staff principals** — human and agent share the layer + but not blast radius: no standing credential, conduit or engine API only, + agent memory is not a state plane, every action reconstructable as the + caller's. +5. **§9.7 puts time into the model** — explicit lifetimes, revocation visibility + deadlines, consumption as a state change never inferred, and the three race + modes named. **§9.8** states what holds under partition and leaves the rest + open. +6. **§17 requires the Taxonomy artifacts** — claim, decision-record, gap-record, + and emission-cadence schemas — without which §6.2 and §11 are reviewable but + not compileable. Ownership proposed, not assigned. +7. **§18 composes the sibling standards** — how zone stance, tenancy posture, + and a credential lifecycle event each enter a decision as a claim. They were + cited in frontmatter and nowhere in the rules. +8. **§5 gained a sunset** on the uncatalogued-infrastructure carve-out, and + §5.3 **declines** a proposed fourth "operator of third-party Tooling" shape: + it would convert a tracked gap into a permanent allowance. +9. **§10 gained the six artifacts** a layer change must carry, written from the + `zone-engine` case, including a permission freeze during the cut. +10. **§2 lifts the observation rule** — no estate argument may cite observation + that has not happened. **§13** separates its three normative rules from the + table, which is now a snapshot due to move into `maturity-engine`. +11. **§16** the approval custody question is **decided: no**, rather than left + open. **§19** records the fitness verdict, including that the estate can + propose and decide but cannot yet watch or act. + +v0.4 → v0.5, all from review findings: + +1. **§9.1 split into two marks** — `pending` (no route, capability zero) and + `declared-gap` (route exists under §5.3, capability works and is tracked). + v0.4's single mark would have forced a false `pending` onto ops-warden's + production SSH issuance. Raised by `ops-warden`. +2. **§9.3 rewritten** — input degradation is the engine's; engine-unreachability + is necessarily the consumer's, bounded by a declared, auditable, total stance. + Contested by `flex-auth`: fail-open is not expressible by a PDP, and v0.4 + collided with `ops-warden` `ADR-0009`. +3. **§5 gained a scope rule** — "Tooling-layer system" means a §4 Tooling row; + uncatalogued infrastructure is outside §5 and recorded rather than policed. + Without it every Staff repository was in undeclared violation for writing + progress events. Raised by `ops-warden`. +4. **§9.4 requires a local outbox** — no synchronous dependency on `audit-core` + inside the state-change transaction, so an audit outage cannot block a + revocation. Raised by `audit-core`. +5. **§9.5 forbids compiling maturity levels into registry content** until + decision provenance carries a registry-snapshot digest. Raised by `flex-auth`. +6. **§9.6 gained the load-bearing / attributive distinction**, the mirror rule + that absence is not evidence of non-occurrence, the optimistic-bias + consequence for adaptive systems, and silence-as-signal. Raised by + `kings-guard` on top of `audit-core`'s original. +7. **§11 gained a fourth state** — blocked-clean, which MUST NOT rank below + conforming — and a machine-readable declaration form. Raised by `kings-guard` + and `audit-core`. +8. **§13 gained state and owner-status columns** — declared-contact versus + unowned-capability, proposed versus assented owner. `access-engine`'s + decline of authentication evidence is recorded. Raised by `kings-guard` and + `flex-auth`. +9. **§8** records the asymmetry's payoff under incomplete observation; **§12** + records that its fourth step is unstaffed; **§14** corrects the adoption + arithmetic and the status contradiction. + +Amended in place while `proposed`, 2026-08-28: §11 gained the who-must-declare +rule after a conformance sweep found the standard required an `INTENT.md` +declaration from `OpenBao`, which the estate does not author; and §14 gained the +honest adoption count. + +v0.3 → v0.4: + +1. **§4 catalog gained `audit-core`** as an Engine, on its own declaration. v0.3 + named it as an owner in §9.4 and §13 without cataloguing it — a §11 defect in + the standard itself, raised by `audit-core`. +2. **§9.4 evidence rationale rewritten** to cite `audit-core`'s shipped + `docs/integrity.md` bound rather than its INTENT principle 6, and to state + that `tamper_evidence` is conditional on live preconditions. +3. **§9.4 gained emission atomicity** as `approval-engine`'s obligation, and the + prohibition on `audit-core` exposing an approval-validity query. +4. **§9.6 added** — evidence proves alteration and truncation, not omission at + source. Estate-wide; the sound and unsound forms of the claim are stated. +5. **§13** — evidence half recorded as assented with conditions; two new gaps: + stronger approval custody (unassigned) and emission atomicity + (`approval-engine`). + +## 16. Open questions + +- ~~Whether approvals warrant archival custody stronger than every other audit + source.~~ **Decided (§13): no.** Approval evidence carries the same bound as + every other source. The acute risk for approvals is *omission* — a suppressed + revocation — and archival custody does not address omission at all; emission + atomicity with a local outbox (§9.4) and a detection surface + (`GH-WP-0002-T04`) do. Leaving it open while calling the evidence half + load-bearing created a promise the archive cannot cash. If a future + requirement genuinely needs WORM or a transparency log, that is a different + store with a different owner, raised then. +- Whether SSH certificate issuance evidence is load-bearing or attributive + (§9.6). Ruled attributive here on the argument that no control branches on the + presence of a signing record; `ops-warden` asked for the ruling and the trade + is genuinely two-sided, so it is flagged rather than settled. +- Who marks an approval consumed, and at what point relative to the decision + (§9.4). `flex-auth` notes the decision precedes the action and the action + precedes consumption, so an allow rendered against an approval then never + consumed, or consumed twice by a racing caller, is a gap neither engine closes + alone. Needed before `FLEX-WP-0017` T05. +- Whether other §4 repositories are missing layer declarations; `audit-core` + flagged its own absence and asked whether the catalog needs the same + correction elsewhere. +- Whether the gap register migrates from this standard into `maturity-engine` + once that engine exists, leaving the standard to state the rules only. +- Whether Tooling warrants subdivision between third-party and homegrown. +- How a future `role-engine` divides responsibility with `access-engine`. +- Whether declared gaps need an estate-wide register rather than per-repository + declarations; ops-warden's `warden route gaps` is candidate machinery. +- Whether non-security repositories adopt the same model. + +--- + +# 17. Taxonomy artifacts + +§6.2 says doctrine reaches a decision as an input claim or a versioned policy +rule. As prose that is a rule a reviewer can apply. As an interface it does not +exist, because nothing defines what a claim *is*. §11 calls itself mechanically +checkable while resting on that gap. + +Four artifacts are therefore required, owned by Taxonomy and versioned like any +standard: + +| Artifact | Contents | +| --- | --- | +| **request-claim schema** | identity, tenant, zone stance, posture, approval, maturity, assurance — each with its issuer and freshness rule | +| **decision-record schema** | policy package digest, input-claim digests, verdict, obligations, and the lifetime required by §9.7 | +| **gap-record schema** | the §5.3 fields — `capability`, `intended_owner`, `blocked_on`, `review` — plus the §13 `state` and owner-status | +| **emission-cadence declaration** | the expected rate a source publishes, so silence is a finding (§9.6) | + +Until these exist, §6.2 and §11 are reviewable but not compileable, and every +engine invents its own claim shape at its own boundary. + +**Ownership is proposed, not assigned.** `info-tech-canon` holds ecosystem-wide +semantic contracts and `net-kingdom` holds NetKingdom standards of record; the +split between them for these four artifacts is theirs to draw, and §2 keeps +ownership in the owning repository's `INTENT.md`. Neither has assented. + +# 18. Composition with the sibling standards + +The related-standards list has been frontmatter and little else. If the +following sentences cannot be written, the list is decoration — so they are +written here rather than in the siblings. + +**Zone stance** (`security-zones_v0.1`). A zone answers which scrutiny a +workload has qualified for; membership is `zone-engine`'s. The *effect* of a +zone on a decision belongs in a versioned `access-engine` policy package, never +in registry content — that ruling is zone-engine's §5, and §6.1 is its +generalization. Zone stance therefore enters a decision as a **claim on the +request or a rule in the package**, and a decision that turned on a zone must +name the package version that read it. + +**Tenancy posture** (`tenancy-posture_v0.1`). Posture is a bounded security-state +input, published by its owner and never a privilege source (§8). It enters as a +**claim**, carries its own freshness, and the §8 asymmetry binds it: posture may +tighten a decision and may never loosen one. A posture too stale to trust is a +missing claim, and a missing claim is not permission. + +**Credential lifecycle** (`credential-management_v0.2`). Issuance, rotation, and +revocation are `secrets-engine`'s and `OpenBao`'s, downstream of a decision — a +credential is an artifact of authority, never its source. A lifecycle event +becomes an **input** to a later decision as a claim (this credential is current, +this lease is bound to this task), never a side channel that changes an outcome +without appearing in the decision record. Revocation visibility is bounded by +§9.7. + +Each of the three composes the same way, which is the point: **facts arrive as +claims, effects live in versioned policy, and anything that changes an outcome +appears in the decision record.** + +# 19. Verdict on fitness + +Recorded so the standard does not overstate itself, from the 2026-08-29 +independent assessment and unchanged by v0.6: + +As a **layering constitution** the model works. It distinguishes deciding from +recording, a gap from a lie, and a missed tightening from an invented privilege. + +As a **self-healing framework** it is incomplete in a specific way. Cognition +(Staff), authority (`access-engine`), and execution (Tooling) are specified. +Evolution works — six versions exist because reviewing repositories used the +loop. The two verbs that make a loop *heal* do not: observation in production is +unstaffed (§12), and actuation has no surface at all (§9.2). + +v0.6 names both rather than closing them. Naming is what the standard can do; +closing them is work, and the honest position is that the estate can currently +propose and decide but cannot watch or act. diff --git a/history/2026-08-29-layering-standard-assessment.md b/history/2026-08-29-layering-standard-assessment.md new file mode 100644 index 0000000..5bed7d2 --- /dev/null +++ b/history/2026-08-29-layering-standard-assessment.md @@ -0,0 +1,261 @@ +# Task + +I am exploring a dynamic, self healing and evolving it-security framework framework and the provided document is a layering model for it. Please review it intensely and provide a SWOT style analyses along with gaps you might see and a list of improvements to improve the framework layering model. + +Document: security-layer-model_v0.5.md + +# Result + +This is an unusually tight layering standard. It is not a Zero Trust slide deck and it is not an org chart. It is a **repository constitution**: determinism vs. non-determinism, one policy decision point, and an honest account of what audit evidence can and cannot prove. That last point is rarer than most security frameworks admit. + +The analysis below treats v0.5 as a living constitution for a self-healing security estate, not as a finished product. + +--- + +## What the model actually is + +Four layers, split by **what they produce** and **whether the same inputs yield the same outputs**: + +| Layer | Job | Deterministic? | +|---|---|---| +| Taxonomy | Shared language and standards | n/a | +| Tooling | State and infrastructure | yes | +| Engines | Concept APIs; every enforcement boundary | yes | +| Staff | Judgment, ops, agents, change | no | + +The load-bearing rules are: + +1. Staff never touches catalogued Tooling except as a declared diagnostic, a no-authority conduit, or a tracked gap. +2. `access-engine` is the only policy decision point. Doctrine that affects an outcome must arrive as a request claim or a versioned policy rule. +3. Adaptive systems may tighten authority. They may never manufacture it. +4. An append-only archive proves alteration and truncation after arrival. It does **not** prove a source emitted the event. Absence is not non-occurrence. + +That is a stronger epistemic stance than most “immutable audit log” claims. + +--- + +## SWOT + +### Strengths + +**Determinism as the layer cut.** Most estates slice by network tier, team, or cloud account. This one slices by whether a component is allowed to *judge*. That is the right cut for an agentic Staff layer. A repository that infers is Staff even if it runs 24/7. + +**Single PDP, written as an invariant rather than a preference.** §6 and §6.1 close the usual failure mode: a cache, registry, or compiled maturity level that decides early. That is the same failure NIST ZTA and XACML architectures spend a lot of ink on, and most estates still ship it as “just a lookup.” + +**Conformance that does not punish restraint.** `blocked-clean` vs `declared-gap` vs `undeclared violation` is the best part of the standard. A repository that left a capability at zero is not graded below one that opened a quiet client. That is how you stop the model from being gamed by relabelling. + +**Evidence doctrine that matches physics.** §9.6 plus the load-bearing / attributive split is estate-grade thinking. The local-outbox rule in §9.4 is the operational consequence: an audit outage must not block revocation. + +**Asymmetry under incomplete observation.** If kings-guard can only reduce authority, a suppressed event can miss a tightening. It cannot invent privilege. That is the correct damage bound for an adaptive system fed by a stream it cannot prove complete. + +**The standard eats its own findings.** Five versions exist because reviewing repositories used the loop. That is more valuable than a prettier first draft. + +**Scope honesty.** Uncatalogued infrastructure is *outside* §5 rather than silently in violation. Painful, but correct: a rule that puts every Staff repo in breach on day one will be ignored. + +### Weaknesses + +**The self-healing loop is specified, not staffed.** §12 step four is explicit aspiration. kings-guard has never observed a real event. Containment has no engine surface. So the estate can *propose* and *decide*, but it cannot yet *watch* or *actuate* as a closed loop. That is the gap between a layering model and a self-healing framework. + +**Engine proliferation without a role map.** The catalog now has user, tenant, zone, secrets, audit, access, approval, and maturity engines. Several of those are Policy Information Points feeding one PDP, not peer decision points. The standard forbids a second decision surface, but it does not name the PEP / PIP / PAP split, so teams will keep inventing “just one more engine.” + +**Adoption is still a review note, not a declaration.** Seven of sixteen estate-authored repos have declared in their own voice. The rest carry gate-house notes. The standard correctly refuses to count those as adoption. Until the remaining nine answer, the catalog is partly fiction. + +**Taxonomy is thin relative to its job.** `info-tech-canon` and `net-kingdom` own language, but there is no versioned semantic contract between engines (claim schemas, decision-record shape, gap-record schema). Without that, “doctrine reaches the decision as an input” is a prose rule, not an interface. + +**The Tooling carve-out is a pressure valve that will grow.** State Hub, `llm-connect`, and “similar” are out of §5 because Staff writes progress events. That is honest. It is also how a second persistence plane forms under the Staff layer — exactly what §3.4 forbids in spirit. + +**Cognitive load of the standard itself.** v0.5 is dense, self-referential, and written for people who already live in the estate. That is fine as canon. It is a poor onboarding artifact for the nine undeclared repos, and a poor contract for agents that are supposed to *conform* to it. + +**Rename and dual-name debt.** `flex-auth` / `access-engine` is still in flight. Dual names in a “ruled name” estate are themselves a taxonomy defect. + +### Opportunities + +**Make the model the control plane for agents, not only for git repos.** Staff is already defined as agentic. The conduit shape (§5.2) plus “no privilege from cognition” is a ready-made autonomy gate: an agent may run the owner’s tool under the caller’s identity and nothing else. That is a better agent-security primitive than most 2026 control-plane writeups, which still centralize a gateway and hope. + +**Promote maturity-engine from seeded idea to the gap register.** §13 already says the table should not outlive that engine. Doing that turn is how the standard stops being both rulebook *and* work tracker. + +**Silence-as-signal.** Expected emission cadence as a first-class finding does not need a Tooling client or an engine gap. It is the cheapest completeness control the estate can add, and it is the one adaptive systems actually need. + +**Export the layering cut beyond security repos.** §16 already asks this. If non-security Staff also cannot hold runtime-dependent state, the estate gets one constitution instead of a security ghetto. + +**Map onto the PDP / PEP / PIP vocabulary without surrendering the determinism cut.** The NetKingdom cut is stricter and should stay primary. The IETF/NIST terms are how you talk to the rest of the industry and how you stop PEPs from quietly becoming PDPs. + +### Threats + +**Convenience second decision points.** The failure mode is already quoted from zone-engine: it arrives as a small convenience. Maturity levels in a registry, approval-validity queries on audit-core, posture caches in kings-guard, “just this once” SSH signing — all of these are the same threat. + +**Optimistic bias in the adaptive layer.** §9.6 already states it. If observation stays fixture-based, posture will look healthy because the stream is well-formed and incomplete. Confidence scores computed from richness of the record in hand will lie. + +**Consumer fail-open as undeclared policy.** §9.3 correctly says unreachable-engine behaviour is the consumer’s, and must be declared, total, and auditable. The threat is drift: `z0`–`z2` open plus “unknown” open becomes the real policy of the estate, and nobody compiled it into the versioned package. + +**Staff agents plus uncatalogued infra.** Progress-event writers today are State Hub and `llm-connect`. Tomorrow they are agent memory stores, tool-call traces, and prompt caches. Those are state other layers will start to depend on. + +**Relabelling under pressure.** The standard exists because a rule with no lane for a real case gets satisfied by renaming. Incident week is when that pressure returns. “Engine unreachable is not grounds for a Staff break-glass path around a *reachable* engine” will be the sentence someone tries to stretch. + +**Supply chain of third-party Tooling.** OpenBao is catalogued; its operator, plugins, and lease semantics are not. A layering model that treats vendored Tooling as a row in a table will miss the place where most secret-plane incidents actually start. + +--- + +## Gaps + +These are gaps in the *layering model*, not a punch list of missing products. Several are already named in §16; they are restated only where the model, not the backlog, is incomplete. + +### 1. No Policy Enforcement Point +The standard is precise about the decision and almost silent about the gate. NIST ZTA splits PDP (decide) from PEP (open, monitor, tear down). Here, ops-mason builds routes, ops-warden issues certs, and “the consumer” fails open or closed — but nothing is catalogued as the component that *must* refuse to proceed without a decision record. Without a PEP rule, enforcement will keep living inside Staff runbooks. + +### 2. Engines are not typed +`access-engine` is a PDP. `user-engine`, `tenant-engine`, `zone-engine`, `approval-engine`, `maturity-engine` are PIPs (or object stores with deterministic APIs). `audit-core` is an evidence plane, and §9.4 already forbids it from becoming a decision plane. `secrets-engine` is a lifecycle API over Tooling. Collapsing all of that under “Engine” hides different failure modes: a PIP outage is input degradation (§9.3); a PDP outage is consumer residue; an evidence-plane outage must not block revocation. + +### 3. Actuation is unnamed +Self-healing needs four verbs: observe, evaluate, decide, actuate. Observation is kings-guard (unstaffed). Evaluation is maturity-engine (seeded). Decision is access-engine. Actuation — reduce authority, step-up, isolate a workload — is “containment, pending.” A layering model for a self-healing framework that has no actuation surface is a diagnosis machine, not a healing machine. + +### 4. Human Staff vs agent Staff +§3.4 treats Staff as one layer because both are non-deterministic. That is right for permissions. It is wrong for blast radius. An agent that can open a conduit, write progress events, and propose doctrine is a different principal from a human with a workplan. There is no agent identity, agent mandate, or agent-memory rule. + +### 5. Time, races, and consumption +§16 already flags who marks an approval consumed, and that the decision precedes the action which precedes consumption. The layering model has no temporal law: decision TTL, revocation visibility, replay windows, and “allow rendered then never consumed.” Those are not engine details. They are what stops the single PDP from deciding on stale claims. + +### 6. Partition and unreachability are one-dimensional +§9.3 handles “engine not reachable.” It does not handle split brain, partial PIP reachability, clock skew, or two consumers with different declared stances seeing different worlds. A self-healing estate will spend most of its incident time in that grey band. + +### 7. Information flow and data classes are absent +Layers constrain *who may own a concept*. They do not constrain *which facts may flow where*. Zone stance, tenant facts, secret metadata, and approval objects all cross the Staff/Engine boundary as claims. Without a claim-schema and classification rule, §6.2 is unenforceable by construction. + +### 8. Layer change is underspecified +§10 says record a decision, update INTENT, get assent, no gradual practice. It does not say what happens to live state, clients, or declared gaps during the cut. `zone-engine` already changed layer in practice. That is the case the procedure should have been written from. + +### 9. Publication integrity of Taxonomy +Canon is the layer that defines the other layers. There is no rule for how a standard itself is hashed, assented, frozen, or rolled back. The frontmatter is careful; the publication path is not a layer concern yet. For a framework that claims reconstructability, the standard-of-record should be an artifact with the same provenance discipline it demands of decisions. + +### 10. The conformance loop has no stop condition +A finding that a rule is unsatisfiable is a success. Good. There is no rule for when a contested clause stays `proposed`, when veto is in-scope, or when two assented repos disagree after adoption. v0.4 §9.3 colliding with shipped `ADR-0009` is the preview. + +### 11. Related standards are cited, not composed +`security-zones`, `tenancy-posture`, and `credential-management` appear in frontmatter and almost nowhere in the rules. The layering model does not say how a zone stance or a tenancy posture *enters* a decision as a claim. That is the composition gap between “we have standards” and “the PDP can see them.” + +### 12. Third-party Tooling has no operator layer +OpenBao is Tooling. The humans and agents who operate it, rotate it, and plugin-extend it are Staff. The standard forbids Staff from holding a direct client — except the declared SSH-CA gap, which is the production path. The model needs a first-class “operator of third-party Tooling” shape, or every operational necessity will look like a gap. + +--- + +## Improvements + +Priority is what would make this a *self-healing and evolving* framework rather than a better catalog. + +### A. Split the Engine layer into roles, keep one decision point + +Keep the four layers. Add a **role** column inside Engines: + +- **PDP** — `access-engine` only +- **PIP / object engines** — user, tenant, zone, approval, maturity, secrets-as-facts +- **Evidence engine** — `audit-core` +- **PEP contract** — not a new repo by default; a *shape* any runtime must implement: no side effect without a decision record, declared unreachable-engine stance, no local recaching of the verdict + +This preserves §6 and stops “we should write an engine for X” from meaning “X now decides.” + +### B. Add an Actuation surface as a first-class pending capability + +Do not assign containment to kings-guard in §4. Assign a **containment API** as an engine concept (likely a small surface on access-engine plus runtime PEPs): reduce, step-up, isolate, with the same reconstructability rules as any other decision. Until that exists, the framework cannot heal. Mark it `pending` and keep the capability at zero. That is already the standard’s own medicine. + +### C. Distinguish Staff-human and Staff-agent in §3.4 / §5 + +Same layer, different principal: + +- Agents get no standing credential. +- Agent tool use is only §5.2 conduit or an Engine API. +- Agent memory and traces are not Tooling other layers may depend on unless catalogued. +- Every agent action is reconstructable as the caller’s action, with the same §9.6 bound. + +That is how “no privilege from cognition” survives an autonomous Staff layer. + +### D. Make Taxonomy operational: versioned claim and decision schemas + +Add a single ruled artifact, owned by Taxonomy: + +- request-claim schema (identity, zone, posture, approval, maturity, assurance) +- decision-record schema (policy package digest, input-claim digests, verdict, obligations) +- gap-record schema (the §5.3 fields, already almost there) +- emission-cadence declaration (silence-as-signal) + +Then §6.2 and §11 “mechanically checkable” become compileable instead of reviewable. + +### E. Close the observation hole without pretending it is closed + +Two concrete rules, both already implied: + +1. No estate argument may cite “kings-guard observed X in operation” until that repo reports a real-event test. §12 already says this; lift it into §2 authority so it cannot be forgotten in a slide. +2. Every source that emits load-bearing or adaptive-relevant events MUST publish an expected cadence. A drop is a finding. That gives the adaptive layer a completeness signal that does not require a Tooling client. + +### F. Put time into the model + +Add a short § on decision lifetime: + +- every allow has an explicit TTL or binding to a session/obligation +- revocation and supersession have a visibility SLA at the PDP and at PEPs +- consumption of an approval is a state change in `approval-engine`, never inferred from a decision record +- racing double-consume and allow-without-consume are named failure modes with owners + +This is the missing law for the approval race already flagged in §16. + +### G. Catalogue PEPs’ unreachable-engine stances as a single register + +`ADR-0009` is the reference. Promote the *shape* (total per-zone map, no implicit default, no per-call discretion) to the standard, and require every PEP-shaped consumer to publish one. Track those maps in maturity-engine once it exists. That turns §9.3 from a ruling into an inventory. + +### H. Shrink §13 out of the standard + +Move the gap register into maturity-engine as soon as it can store state. Leave in the standard only: the two marks (`pending` / `declared-gap`), the owner-status rule (proposed ≠ assigned), and the scoring rule (`blocked-clean` MUST NOT rank below conforming). A standard that is also a backlog will keep attracting findings that belong in the register. + +### I. Tighten the uncatalogued-infra valve + +Keep the carve-out. Add a sunset: + +- every non-Tooling client MUST be listed +- after N review intervals, an uncatalogued store that other layers read is either catalogued as Tooling or declared a gap +- Staff-owned event buses cannot become the de facto state plane + +Otherwise the binding rule dies at the edges. + +### J. Write the layer-change procedure from the zone-engine case + +Required artifacts: before/after INTENT, client inventory, gap inventory, assent list, state-migration decision, and a freeze on new permissions until the cut is complete. “No gradual practice” needs a check, not a sentence. + +### K. Compose the sibling standards in one paragraph each + +In this document, not in theirs: + +- how a zone stance becomes a claim +- how tenancy posture becomes a claim +- how a credential lifecycle event becomes an input rather than a side channel + +If those sentences cannot be written, the related-standards list is decoration. + +### L. Add a two-page “agent-readable” companion + +Same rules, no change log, no review archaeology. Machine-readable layer key, sanctioned shapes, one decision point, evidence bound, four conformance states. v0.5 is the statute. The companion is what the nine undeclared repos and the Staff agents can actually satisfy. + +### M. Decide the open custody question on purpose + +Either approvals warrant stronger custody than other sources, or they do not. Leaving it open while calling the evidence half “load-bearing” creates a slogan the archive cannot cash. If the answer is “same bound as every source,” say that and stop implying a future WORM plane. If the answer is “stronger,” assign an owner *outside* audit-core’s current store — that is the only way the bound changes. + +--- + +## Verdict on fitness for a self-healing, evolving framework + +As a **layering constitution**, v0.5 is already ahead of most enterprise security models: it knows the difference between deciding and recording, between a gap and a lie, and between a missed tightening and an invented privilege. + +As a **self-healing system**, it is incomplete in a specific way. Cognition (Staff) and authority (access-engine) are specified. Execution (Tooling) is specified. The two verbs that make a loop *heal* — observe in production, actuate through a deterministic surface — are pending and, in one case, explicitly unstaffed. Evolution works: the version history is the proof. Healing does not, yet. + +The highest-leverage next version is not another finding-driven prose refinement. It is: + +1. type the engines (PDP / PIP / evidence / PEP contract), +2. keep containment at zero until an actuation API exists, +3. put claim schemas in Taxonomy, +4. staff or retract the observation step, +5. move the gap register out of the statute. + +Do those five and the model stops describing an estate that *intends* to heal and starts describing one that can. + + +Assessment and Research by Grok Expert + +xxx