flex-auth/workplans/FLEX-WP-0030-boundary-declaration-cleanup.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	planning_priority	planning_order	related_workplans	created	updated	state_hub_workstream_id
FLEX-WP-0030	workplan	The layer declaration pins a version it should not, and four security-relevant peers do not declare at all	infotech	flex-auth	ready	review	claude	netkingdom	P1	300	FLEX-WP-0019 FLEX-WP-0029	2026-09-21	2026-09-21	abe60f5f-79cc-5857-b9e8-a46bed704279

FLEX-WP-0030 — Boundary declaration cleanup and estate boundaries review

INTENT.md declares standard_version: "0.7" in the frontmatter that §11 requires. That conflates two things the standard itself separates. The standard's own frontmatter says it outright:

assented_by records assent to a BOUNDARY, given at the version named. It is not assent to the current text.

A layer is a boundary. flex-auth is Engine / PDP whether the standard is at v0.6, v0.7, v0.8 or v1.0 — the role does not change when the text is amended. Pinning a version in the boundary declaration makes every standard revision look like it invalidates the declaration, and generates exactly the churn seen this month: v0.8 lands, the file still says 0.7, and a reader cannot tell whether that is staleness or a deliberate position.

It is also decorative. internal/layer/conformance.go:40 parses standard_version into Declaration.StandardVersion and ValidateDeclaration never reads it. The field is enforced by nothing, in a file whose entire purpose is being mechanically checkable.

1. Make the declaration version-agnostic

id: FLEX-WP-0030-T01
status: done
priority: high
state_hub_task_id: "016ab184-e814-591b-938b-24ff9ace5ede"

Owner: flex-auth.

• Drop standard_version from the INTENT.md frontmatter. §11 requires a layer: key; it does not require a version, and flex-auth's own validator does not check one.
• Replace versioned prose references (security-layer-model_v0.7.md) with the unversioned standard path. INTENT.md is declared "aspirational and stable" in its own words; a stable file should not carry a number that moves quarterly.
• Move version-scoped conformance state out of INTENT.md into a conformance record that is supposed to move: which version was reviewed, the conformance state, and each declared gap with owner, blocker and review date (§11's four-state table).
• That split also satisfies §11's derived-artifact rule, which requires a derived artifact to name what it derives from and the version it was derived at. The boundary declaration is not derived; the conformance record is, and it is the artifact that should carry the version.
• Keep internal/layer green, and decide whether StandardVersion stays as a tolerated-but-unused field or is removed. Do not leave a parsed field that nothing validates without saying which it is.

Gate: INTENT.md names no standard version; conformance state is version-stamped somewhere that is maintained; go test ./internal/layer/... passes.

2026-09-21: done. standard_version removed; conformance_record added. The test that pinned 0.7 was inverted rather than deleted — internal/layer now rejects a version pin in the declaration and requires conformance_record to name a file that exists on disk. StandardVersion is kept on the struct deliberately, documented as must-stay-empty, so a reintroduced pin fails loudly instead of being silently ignored. Version-scoped state is in docs/conformance/security-layer-conformance.md. Full suite green.

2. Update SCOPE.md and assess the gaps

id: FLEX-WP-0030-T02
status: done
priority: high
state_hub_task_id: "224cd214-7226-5286-9794-a8a6d36c25e5"

Owner: flex-auth.

SCOPE.md's Current State is accurate but drifting: it says §13.1's register has two rows (it has five — FLEX-WP-0029 owns that), and it states conformance as "conforming with one declared gap" without naming where the gap list is maintained.

Assess and state, per gap: what it is, who owns it, what unblocks it, and when it is next reviewed. Known candidates:

Candidate gap	State
Registry-snapshot digest in decision provenance	declared, FLEX-WP-0019, §9.7.2 conformance prerequisite
Emission guarantee not declared (see T04 / B3)	unassessed — may be a second declared gap
Stance-register review stale at five rows	FLEX-WP-0029

Gate: every gap in SCOPE.md has an owner and a route; no gap is described only as a sentence.

2026-09-21: done. Three gaps, each with owner and route. G2 (emission guarantee) is newly assessed and recorded as a gap rather than as conformance, because the flattering reading has been asserted by nobody but flex-auth. Register corrected from two rows to five. All v0.7 references removed from SCOPE.md.

3. Publish the boundaries review

id: FLEX-WP-0030-T03
status: done
priority: high
state_hub_task_id: "7d45a3d6-d4a7-556a-8607-58086f74a998"

Owner: flex-auth.

Review flex-auth's boundary against every security-relevant repository it names or is named by, and publish findings as a derived artifact marked with the version it was derived at. Five findings are already identified in T04; the review is the durable form of them.

Cover at minimum: gate-house (doctrine), key-cape (identity claims in), ops-warden, secrets-engine, user-engine, tenant-engine, zone-engine, approval-engine, audit-core, maturity-engine, kings-guard, ops-mason.

Gate: the review states, for each counterpart, whether the boundary is agreed, contested, or unstated — and does not record "unstated" as if it were "agreed".

2026-09-21: published at docs/conformance/boundaries-review.md, marked derived and version-stamped. Twelve counterparts. Seven agreed, one agreed-in-substance but undeclared (gate-house), one asserted from one side only (key-cape), one held unilaterally and unconfirmed (zone-engine), two unclear (tenant-engine on CheckRequest.tenant, audit-core on evidence source), one undeclared twice over (ops-mason).

4. Raise the conflicting and unclear boundaries for resolution

id: FLEX-WP-0030-T04
status: progress
priority: high
state_hub_task_id: "70786e6d-02f2-5a90-8640-247ba377d9a4"

Owner: flex-auth to raise; the named owner resolves each.

B1 — nine of nine repositories disagree with themselves across the two §11 forms

Corrected 2026-09-21. The first version of this finding said the estate spelled layer: three ways across repositories and named eight as non-conformant on casing. That was wrong, from an ad-hoc shell survey that took the first ^layer: match per repository without recording which file it came from.

Re-run mechanically (tools/survey_layer_declarations.go, receipt at docs/evidence/2026-09-21-layer-declaration-survey.json):

Repositories carrying both §11 forms	9
Of those, forms that disagree	9 of 9
Shape	INTENT.md: Engine / Staff. layer.yaml: engine / staff
Only one form	flex-auth — no layer.yaml, which is why it cannot exhibit this

The disagreement is within each repository, not across the estate, and it is universal rather than careless: two generators, two conventions, no repository mixing them. Nobody is inconsistent with anybody else.

§11 accepts "a layer: key in the INTENT.md frontmatter, or an equivalent declaration file" and does not say which governs when both exist and disagree. A conformance run reading INTENT.md and one reading layer.yaml reach different answers for nine repositories, and both follow §11. That is the finding: not casing, but an unruled precedence between two permitted forms.

Owner: gate-house. Two things would resolve it — which form governs, and whether the §3 vocabulary is case-sensitive. If it is case-insensitive, the casing half evaporates and flex-auth's validator is what changes; the precedence half does not.

B2 — four security-relevant repositories carry no layer declaration

gate-house, key-cape, ops-mason, and net-kingdom have no layer: key in INTENT.md and no equivalent declaration file. §11 requires one of every estate-authored repository in §4, and is explicit that a layer stated about a repository by another repository is not a declaration.

Two matter directly to flex-auth:

• key-cape is the identity source whose verified claims flex-auth consumes as normative input and never redefines. That boundary is load-bearing for every decision flex-auth renders, and it is asserted only from flex-auth's side.
• gate-house authors the obligation. A doctrine owner that has not discharged its own §11 obligation is the standard's §9.1 defect pointed at itself.

ops-mason is already marked non-conformant in §13.1 for publishing no stance map; a missing layer declaration is the same gap one level up.

Owner: each named repository. flex-auth raises, does not grade.

B3 — flex-auth declares no emission guarantee, and may owe one

§11 requires every repository catalogued in §4 as a source of evidence to declare its emission guarantee — class, cadence, and detection surface — in its machine-readable layer declaration, and says a source that declares none is not conforming.

flex-auth produces the decision record, which §17 moved to flex-auth as its own contract and calls "the one thing in the estate only access-engine produces". flex-auth's frontmatter declares no emission guarantee.

The unclear boundary is whether flex-auth is a §4 source of evidence or merely the producer of an artifact that audit-core is the source of. The answer decides whether this is a second declared gap or nothing at all. flex-auth should not answer it alone, and should not assume the flattering reading.

Owner: gate-house to rule; audit-core to confirm which side of the line it holds.

B4 — the declaration pins a version the standard says is not part of the boundary

Raised here as the general form of T01, because if flex-auth is right that a layer declaration should not carry a standard version, the fix belongs in §11 and not only in flex-auth's file. If §11 wants a version, it should say so and say what it means when the standard moves.

Owner: gate-house.

B5 — canon names a repository that does not resolve

v0.8 refers to the PDP as access-engine throughout (§4 catalog row, §13.1, §17), while the repository, runtime, namespace, images, and API vocabulary all remain flex-auth per FLEX-DEC-2026-013, and the rename has not landed — access-engine raw returns 404, verified 2026-09-20 under FLEX-WP-0020.

Neither side is wrong: the rename is ruled and sequenced, and canon named the end state. But a reader of v0.8 cannot resolve the repository it keeps naming, and reuse-surface already probed the 404 independently. Worth one line in the standard recording that the coordinate is pending rather than broken.

Owner: gate-house to note; flex-auth to ping when FLEX-WP-0020 lands.

Gate: every finding above is sent to its named owner with what would resolve it. An unanswered finding stays open and is not closed by silence.

2026-09-21: eleven messages sent. gate-house (all five findings), key-cape (B2, one-sided identity boundary), audit-core (B3, evidence source), ops-mason (B2), net-kingdom (B5 plus the vendored-vs-authored question), zone-engine (membership/stance confirmation), tenant-engine (the live unclear boundary, restated with its standing), and B1 as a heads-up to the five affected engine repos — sent as an estate property, not as a finding against any of them, since no repository could have discovered it from inside its own checker.

Task stays progress: every finding is open until its owner answers. None is closed by silence.

2026-09-21 (later): B1 was sent wrong and corrected the same day. See T05. Corrections went to gate-house and the five engine repositories that received the original, plus ops-warden, kings-guard and audit-core, who are affected by the corrected finding and had not been told of the first.

Out of scope

• Bumping flex-auth to declare v0.8. v0.8 is status: proposed; T01 removes the version from the declaration entirely, which makes the question moot rather than answering it.
• Grading any peer repository's conformance. flex-auth reports what it can observe and names the owner; §9.3's two-owner split cuts here too.
• FLEX-WP-0029's stance-register second edition. Adjacent, separately owned.

5. Make the survey reproducible

id: FLEX-WP-0030-T05
status: done
priority: high

Owner: flex-auth.

B1 was found with a shell pipeline and published as a finding. The review it appeared in had already argued that a mechanical check nobody can re-run is an assertion — and §11's whole claim is mechanical checkability. Asserting B1 unmechanically was that defect committed by the repository reporting it.

tools/survey_layer_declarations.go reads both §11 forms for every security-relevant counterpart, reports intra-repository disagreement, and writes a JSON receipt. internal/layer carries four tests covering the disagreement case, the refusal to fold case, a missing declaration, and the single-form shape that must not be reported as disagreeing with itself.

It checks exactly one property — the layer: value against the §3 vocabulary as written — and deliberately does not apply flex-auth's own declaration rules (pep_stance, tooling_contacts, conformance_record) to any other repository. Grading peers by the surveyor's house rules would be §11's own defect wearing a tool for a hat.

Running it immediately falsified the finding it was built to reproduce, which is the argument for building it.

Gate: B1 is reproducible by command, with a receipt, and the correction is recorded rather than edited away.

2026-09-21: done. Receipt at docs/evidence/2026-09-21-layer-declaration-survey.json.