net-kingdom/canon/standards/security-layer-model_v0.6.md

id	type	title	domain	status	version	supersedes	owner	publication_owner	created	updated	last_reviewed	review_interval	source_revision	standard_token	assented_by	related
netkingdom-security-layer-model-v0.6	standard	NetKingdom Security Layer Model v0.6	netkingdom	proposed	0.6	canon/standards/security-layer-model_v0.5.md	gate-house	net-kingdom	2026-08-28	2026-08-28	2026-08-28	3m	gate-house@516ed4e	security-layer-model_v0.6	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	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

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:

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.