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

id	type	title	domain	status	version	supersedes	owner	publication_owner	created	updated	last_reviewed	review_interval	source_revision	standard_token	superseded_by	assented_by	related
netkingdom-security-layer-model-v0.4	standard	NetKingdom Security Layer Model v0.4	netkingdom	superseded	0.4	canon/standards/security-layer-model_v0.3.md	gate-house	net-kingdom	2026-08-28	2026-08-28	2026-08-28	3m	gate-house@516ed4e	security-layer-model_v0.4	canon/standards/security-layer-model_v0.5.md	flex-auth FLEX-DEC-2026-001 kings-guard KG-DEC-2026-001 ops-warden ADR-0010 audit-core AUDIT-IN-0001 (evidence half, assent with conditions)	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 gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md

NetKingdom Security Layer Model v0.4

Superseded 2026-08-29 by v0.5. All four reviewing repositories returned findings; flex-auth contested §9.3 and was right. v0.5 splits §9.1 into two marks, rewrites §9.3, scopes §5, requires a local outbox in §9.4, and gives §11 a fourth conformance state.

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.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

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.

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.

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	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	users, accounts, memberships
tenant-engine	Engine	tenant-as-an-entity facts
zone-engine	Engine	zone identity and membership — offline reference conformance per its 2026-08-23 disposition
secrets-engine	Engine	credential abstraction, custody, lifecycle
audit-core	Engine	audit event custody, retention, integrity verification, export — explicitly not a decision point (§9.6)
access-engine	Engine	the policy decision — the only decision point (§6)
approval-engine	Engine	the approval object — durable, authenticated, consumable, atomically supersedable (§9.4)
maturity-engine	Engine	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	building and tearing down access routes and perimeters
ops-warden	Staff	operational access lanes, stewardship, runbooks; SSH certificate issuance
kings-guard	Staff	adaptive defence, observation; containment — pending (§9.2)
whitehat-security	Staff	offensive validation

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.

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.

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.

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.

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.

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 that requires a Tooling contact no engine exposes. Where the capability is intended but the engine surface does not yet exist, the catalog entry MUST be marked pending and the gap declared under §5.3.

v0.1 violated this: it catalogued kings-guard as owning containment while §5 forbade the only route to discharging it, making the capability zero rather than degraded. Raised by kings-guard, KG-DEC-2026-001.

9.2 Containment is pending an engine surface

No engine exposes a containment surface today — nothing to reduce authority, require step-up, or isolate a workload as a deterministic API. kings-guard's containment claim is marked pending in §4 until one exists.

9.3 Degraded-mode fallback belongs inside the engine

Where a capability must survive partial failure, the fallback belongs to the engine, not to Staff. The deterministic fail to reduced authority default is access-engine's, applied when it cannot reach its own inputs.

This keeps the decision at the decision point and keeps the fallback deterministic — which a Staff-layer fallback could never be. It is also why engine-unavailable is not grounds for a Staff break-glass path: an incident is when an attacker most wants the shortcut, and a containment path that bypasses the decision point becomes an authority path the moment it is subverted.

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 — transactional outbox or equivalent. 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 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 and MUST be respected wherever doctrine relies on audit. 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".

Two consequences:

1. Completeness is the source's obligation, not the archive's. Any system whose evidence is load-bearing MUST make emission atomic with the state change it records (§9.4). An archive cannot retrofit completeness.
2. The most valuable event to suppress is the negative one. A withheld revocation, denial, or containment action is exactly what an adversary wants missing, and it is the case least visible to chain verification. Controls that depend on such events MUST NOT treat archive integrity as evidence of their occurrence.

Raised by audit-core while assenting to §9.4, against its own principle 6.

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.

11. Conformance

Conformance has three states, and the distinction is the point:

State	Meaning
Conforming	no Tooling contact, or only §5.1/§5.2 shapes, declared
Declared gap	a §5.3 contact with owner, blocker, and review date — tracked non-conformance
Undeclared violation	anything else — a finding

Who must declare. A repository the estate authors declares its layer in its own INTENT.md, in its own voice. 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, in its own voice, conforms.

Mechanically checkable:

• every estate-authored repository in §4 declares its layer in its own INTENT.md;
• every direct Tooling client in a Staff repository maps to a declared §5.1, §5.2, or §5.3 entry;
• no repository other than access-engine exposes an authorization decision surface;
• no §4 capability is catalogued without an engine surface or a pending 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. v0.2 exists because three repositories used it on first contact.

13. Open gaps

Declared under §5.3 or raised as unowned capability, as of 2026-08-28:

Gap	Declared by	Intended owner
SSH-CA signing write (VaultCA, bao kv put)	ops-warden	secrets-engine
Authentication / assurance evidence	kings-guard	user-engine, access-engine
Secret-use evidence	kings-guard	secrets-engine
Containment surface	kings-guard	access-engine + runtime engines
Registry-snapshot digest in decision provenance	flex-auth	flex-auth (self-declared)
Approval storage and lifecycle — durable object, authenticated entries, atomic supersession	flex-auth	approval-engine — assigned in v0.3 (§9.4)
Approval evidence — record of issuance, use, supersession, revocation	gate-house	audit-core — assented with conditions (AUDIT-IN-0001)
Approval evidence custody stronger than the shipped bound — WORM, object lock, or transparency log	audit-core	unassigned — declared under §5.3, see below
Emission atomicity for approval state changes	audit-core	approval-engine — condition of the above assent (§9.4)
Conformance review has no engine surface	gate-house (self)	maturity-engine — assigned in v0.3 (§9.5)

The approval gap is resolved in v0.3 by seeding approval-engine (§9.4), which unblocks FLEX-WP-0017 T03 and T05 once implemented. Its evidence half is proposed to audit-core and awaits that repository's assent.

The approval evidence half is assented by audit-core with conditions, and one of those conditions opened a new gap: approvals plausibly warrant custody stronger than the shipped bound — WORM, object lock, or a transparency log — which audit-core correctly says is an engine gap to declare rather than a setting to enable. It is declared here, unassigned, because deciding whether approvals need archival custody distinct from every other source is doctrine work that has not been done. Until it is, approval evidence carries the same guarantee as any other source, and §9.6 bounds what may be claimed from it.

Gaps are recorded here but tracked in maturity-engine (§9.5) once it exists; this table is the interim register and should not outlive it.

14. Adoption

Status is accepted. All three repositories whose boundaries moved have assented in writing, each with a decision record:

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-28: seven of fifteen 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 eight — 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.

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 (§13), and if so which mechanism and who owns it.
• 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.