flex-auth/history/2026-08-29-layer-model-v0.7-alignment-review.md

id	type	title	domain	repo	owner	created	standard	records	workplan
flex-auth-2026-08-29-layer-model-alignment	history	Layer model v0.7 alignment: INTENT, SCOPE, and the gap between them	infotech	flex-auth	flex-auth	2026-08-29	net-kingdom/canon/standards/security-layer-model_v0.7.md	decisions/decisions.md FLEX-DEC-2026-001, FLEX-DEC-2026-002, FLEX-DEC-2026-003	workplans/FLEX-WP-0019-layer-model-conformance.md

Layer model v0.7 alignment review

The NetKingdom Security Layer Model was accepted at v0.7 on 2026-08-29. INTENT.md and SCOPE.md were aligned to it in the same session. This document records what changed, then asks the question the alignment exists to answer: where does the stated scope now outrun the implementation, and what has to be built to close it.

1. How flex-auth arrived at v0.7

flex-auth reviewed three versions and holds three records. Four of its findings became text in the accepted standard:

Finding	Adopted as
§9.3 collapsed two failures with different owners	§9.3 rewritten: input degradation is the engine's, engine-unreachability is necessarily the consumer's
§6.4.2 forbade the session-bound allow §9.7.1 permits	§6.4.2 scoped to the decision's own binding and lifetime, with flex-auth's canonical request digest as the mechanical test, and negative caching ruled permitted where the refusal is recorded
A PDP's visibility deadline is per input class, not one number	§9.7.2 split by role
The decision-record schema is the PDP's output, not Taxonomy's	§17 moves it to access-engine

The last of those was argued against flex-auth's own interest — it takes work on rather than off — and the standard says so, because that is what makes the §2 ownership rule credible when flex-auth also uses it to decline work.

Two of flex-auth's positions were recorded rather than adopted: containment surface ownership stays proposed (§13, pending under §9.2), and authentication/assurance evidence is recorded as declined.

2. What changed in INTENT.md

1. A machine-readable layer declaration in frontmatter — layer: Engine, role: PDP — which §11 requires and flex-auth did not have. audit-core named this precisely: flex-auth's declaration was "legible as one only by following its decision trail." Prose cannot distinguish a declaration from a transcribed review.
2. The PDP role stated with its failure semantics: flex-auth's outage is consumer residue, not input degradation. Fail-open is not expressible by a PDP at all.
3. Four obligations added to what flex-auth owns: the decision-record schema as its own contract, the canonical request digest as the published replay test, a lifetime on every allow, and revocation visibility deadlines per input class.
4. A Layer Conformance section stating the conformance state honestly: conforming with one declared gap, no Tooling client, not PEP-shaped.
5. A vocabulary correction. Earlier versions dropped "control plane" as Staff vocabulary. That reason was wrong on the standard's own terms — §8 binds control plane to the Engine layer, which is why kings-guard was asked to release it. The term is flex-auth's to use. This file prefers "decision engine" as a matter of precision, not boundary.

3. What changed in SCOPE.md

The one-liner now states the layer and role. In Scope gained the four v0.7 obligations. Out of Scope gained five boundaries flex-auth had established in review but never written down: fail-open, enforcement, the approval object, authentication evidence, and doctrine authoring. Three capability blocks were still marked planned for workplans completed in May and are now current, and two capability blocks were added. A superseded citation of ops-warden ADR-0006 was corrected to ADR-0009, which retires the global flag outright rather than deferring it.

4. Scope versus implementation — the gap

This is the operative section. Each row is checked against the code, not against the documents.

#	Obligation	Standard	Implementation today	Gap
G1	Machine-readable layer declaration	§11	INTENT.md frontmatter, added in this session	closed, needs a conformance test
G2	Registry-snapshot digest in decision provenance	§6.1, §9.7.2, §13	DecisionProvenance carries evaluator, mode, policy package, policy version, directory ETag, decision time — no snapshot digest	open — conformance prerequisite
G3	Every allow carries an explicit lifetime	§9.7.1	DecisionEnvelope has no lifetime field. ActionAuthorizationValidity has not_before/expires_at, but that is the durable approval object, not the decision	open
G4	Revocation visibility deadline per input class	§9.7.2	Not stated anywhere — no document, no field	open
G5	Decision-record schema published as flex-auth's contract	§17	schemas/decision_envelope.schema.json exists and describes binding and provenance via $defs. It carries no lifetime, no policy-package digest (name and version only), and no input-claim digests	partial
G6	Canonical request digest as the §6.4.2 replay test	§6.4.2	NewDecisionBinding computes it over normalized subject, action, resource, context; it is in every binding and regression-tested	closed in code, unpublished as consumer guidance
G7	Doctrine reaches the decision as claim or versioned rule	§6.2	Context claims and versioned policy packages both exist	closed
G8	Approvals consumed as input claims, never mutated	§9.4	flex-auth mutates no approval. FLEX-WP-0017 T03/T05 wait on approval-engine	closed on flex-auth's side; blocked externally

Why G2 is the one that matters most

G2 and G4 are the same gap seen from two sides, and the standard now says so in flex-auth's own words. A stated visibility deadline for a fact carried by a registry snapshot is unfalsifiable while provenance holds no snapshot digest, because nobody can determine afterwards which snapshot a decision read. Publishing G4 without closing G2 would be publishing a number nobody can check.

G2 is also cheap. registry.Snapshot is already a deterministic, JSON-serializable struct with a test asserting that determinism (TestStoreLoadsAndSavesDeterministicSnapshot), and pkg/api/canonical.go already carries the canonical-JSON-plus-SHA-256 pattern that NewDecisionBinding uses. The work is to reuse that pattern over the snapshot and thread the result into DecisionProvenance, including through the delegated adapters, which already share the canonical binding constructor.

Why G3 is larger than it looks

Adding a lifetime field is trivial. Deciding what the lifetime is is not: a TTL, a session binding, or an obligation binding, per §9.7.1. flex-auth has no session concept, so the honest first step is a policy-package-declared TTL with an explicit default, and a deny for any allow that would otherwise have no stated end. That is a policy-surface change and needs fixtures, not just a struct field.

A capability flex-auth claimed and cannot yet exercise

flex-auth told gate-house it is the repository positioned to notice when the aggregate of consumer stances diverges from what the policy packages say. §13.1 now exists as the register, and it has one row — ops-warden, with ops-mason catalogued PEP-shaped and unpublished. The claim is sound and the data is not there yet. This is not a flex-auth gap to close alone, but flex-auth should be able to read the register once it is populated, and should say so rather than let the claim sit unexercised.

5. What this does not change

flex-auth's boundaries are unchanged by v0.7. It still does not author doctrine, own approvals, own enforcement, or own authentication evidence. The rename to access-engine remains a separate governed migration under the two conditions in FLEX-DEC-2026-001, and nothing in the alignment starts it.

6. Outcome

FLEX-WP-0019 carries G1's test, G2, G3, G4, G5, and G6. G7 needs nothing. G8 stays with FLEX-WP-0017, blocked on approval-engine.