flex-auth/docs/conformance/security-layer-conformance.md

Security Layer Model — flex-auth conformance record

Derived artifact (§11). Derives from net-kingdom/canon/standards/security-layer-model_v0.8.md (status: proposed, source_revision: gate-house@516ed4e). Derived at: 2026-09-21. Maintained by flex-auth.

This file exists because INTENT.md deliberately does not carry one. The layer declaration states a boundary — flex-auth is Engine / PDP — and a boundary does not change when the standard text is amended. Conformance state does change, every revision, and belongs in an artifact that is expected to move and that carries the version it was derived at.

The split is the standard's own. Its frontmatter: "assented_by records assent to a BOUNDARY, given at the version named. It is not assent to the current text."

Declaration

Field	Value
Layer	Engine
Role	PDP — the estate's only policy decision point (§6)
Declared at	2026-08-29
Declared by	FLEX-DEC-2026-001, FLEX-DEC-2026-002, FLEX-DEC-2026-003
PEP stance	null — not PEP-shaped; flex-auth renders decisions and causes no protected side effect
Tooling contacts	none — §5 binds Staff; flex-auth holds no Tooling client

Assent history

Assent is to the boundary, recorded at the version where it was given.

Version	Record	Outcome
v0.4	FLEX-DEC-2026-002	§9.3 contested and upheld
v0.6	FLEX-DEC-2026-003	review; §6.4.2, §9.7.2, §17 adopted into v0.7
v0.7	—	four flex-auth findings adopted
v0.8 (proposed)	FLEX-DEC-2026-011	assent with four findings, all adopted

Conformance state at v0.8

Scope of this record: one repository, flex-auth, which is the §4 row access-engine. §11 binds §4 and flex-auth is in it, so this is an in-scope record. Stated because a run MUST state its scope (A11, GH-DEC-2026-017 §4).

Not conforming on §11, held as a declared gap. GH-DEC-2026-018 ruled that flex-auth is a §4 source of evidence for the decision record and owes an emission guarantee it did not declare. Recorded in those words, as gate-house wrote them: flex-auth asked for the unflattering reading, and softening it here would make the register useless for whoever is next.

§11's four states: conforming, blocked-clean, declared gap, undeclared violation. flex-auth claims no blocked-clean capability and holds no undeclared violation it is aware of. Everything below is a declared gap: owner, blocker, review date.

#	Gap	Owner	Blocked on	Review
G1	Registry-snapshot digest absent from decision provenance. §9.7.2 promotes it to a conformance prerequisite: a decision that turned on registry content must be replayable from its own record.	flex-auth	implementation	FLEX-WP-0019
G2	Emission guarantee declared, not delivered. Ruled 2026-09-21 (GH-DEC-2026-018): flex-auth is the source; custody is never source; audit-core confirmed its half and declined the role (AUDIT-IN-0005). The per-event-class inventory and classification are published in cadence.yaml and named from INTENT.md (source_of_evidence: true, emission_guarantee). Five decision classes are load-bearing; deny, redact, not_applicable, audit_only are rare — heartbeat and reconciliation, rate monitoring forbidden; allow is volume — expected-rate and reconciliation. Nothing emits yet: no sender is registered with audit-core, no outbox, no heartbeat.	flex-auth	outbox + heartbeat implementation, and an audit-core sender registration (intake + token lane, per AUDIT-IN-0002/0003) — FLEX-WP-0031	2026-10-19
G3	Published stance-register review is stale: written at two register rows, §13.1 now carries five, and its Finding 1 was ruled by v0.8 §6.4 obligation 3.	flex-auth	second edition	FLEX-WP-0029

G2 fails closed. A stream with no delivered cadence produces no silence finding, so the failure on its distinguishing case is a missed detection, never a manufactured permission (A-17, §9.6's §8-asymmetry). That is why it can be held as a gap rather than being a permission. It is still non-conformance, tracked, and it is not closed by the classification being published: a declaration of a guarantee nobody delivers is the §9.1 defect this standard keeps correcting.

What the classification is. flex-auth's, published as §11 requires the source to publish it. GH-DEC-2026-018 §4 declined to classify on flex-auth's behalf because §11 forbids inferring class from event name, payload or observed rate, and that binds a ruling as hard as a runner. A conformance run is supplied this inventory and must not derive it.

Atomicity is pending, not waived. Whether decision-record emission must be atomic with the decision (§9.4) was expressly left open by GH-DEC-2026-018 pending this inventory. It now exists; the question goes to FLEX-WP-0031.

Not gaps

• No standard version in INTENT.md. Deliberate, enforced by test (internal/layer), and raised to gate-house as FLEX-WP-0030 B4 in case §11 should say so generally.
• Canon says access-engine, the repository answers to flex-auth. The rename is ruled (FLEX-DEC-2026-013) and sequenced (FLEX-WP-0020); the coordinate is pending, not broken. Raised as B5.

How this file is kept true

internal/layer asserts that INTENT.md carries no standard_version, names a conformance_record that exists on disk, states source_of_evidence, and — because it is true — names an emission_guarantee that exists on disk and classifies every event class, with every rare load-bearing class carrying heartbeat and reconciliation and forbidding rate monitoring. That is the same property flex-auth praised in ops-warden's stance map: the published artifact is asserted equal to the shipped one by test, rather than merely written down. It does not assert the contents below the declaration — a reviewer still has to read this file.