repo.work.resolve_decision FLEX-DEC-2026-003

correlation_id: fe430c1e-83bb-4dba-b6fc-337baa1a0059
reason: rmgr CLI
source: repo-manager

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014348@bnt-lap001
Assistant-Session: a993abda-65a0-4ea8-8ccd-0fcd78c92ac0

decisions/decisions.md

@@ -352,7 +352,7 @@ id: FLEX-DEC-2026-003
 kind: decision
 title: 'Review of security layer model v0.6 and companion v0.1: assent, two answers,
   five findings'
-status: open
+status: resolved
 origin: cross-repo
 origin_ref: net-kingdom security-layer-model_v0.6 + companion_v0.1
 standard: net-kingdom/canon/standards/security-layer-model_v0.6.md
@@ -369,5 +369,170 @@ requested_dispositions:
 - revise
 - reject
 created: '2026-08-29T08:18:39.602701Z'
-updated: '2026-08-29T08:18:39.602701Z'
+updated: '2026-08-29T08:19:41.832549Z'
+rationale: 'Assent to v0.6 and companion v0.1, with two answers and five findings,
+  none blocking. Q1: section 6.4.2 is right but collides with 9.7.1''s session-bound
+  allow, needs the request digest as its mechanical replay test, and should rule explicitly
+  on deny-caching. Q2: the visibility deadline does land on a PDP and harder than
+  at a PEP, but must be per input class rather than one number, and it makes flex-auth''s
+  registry-provenance gap load-bearing rather than untidy. Findings: 6.4''s stance-map
+  register does not exist in section 13 and neither document says where a map is published;
+  the companion omits it too, which is the sufficiency gap gate-house asked for; section
+  17 puts the decision-record schema in Taxonomy when it is the PDP''s output artifact,
+  inverting the section 2 rule flex-auth used to decline authentication evidence;
+  sections 17-19 are H1 outside the hierarchy; section 19 grades the document it lives
+  in and will age.'
+decided_by: flex-auth (reviewing side)
+decided_at: '2026-08-29T08:19:41.832549Z'
 ```
+
+## Context
+
+gate-house published v0.5 (answering `FLEX-DEC-2026-002`), then v0.6 with a new
+two-page companion, and asked flex-auth to review two rules specifically. This
+record reviews **v0.6 + companion v0.1** and answers both questions.
+
+Every finding in `FLEX-DEC-2026-002` was honored: §9.3 rewritten along the two-
+owner split, §13 given an owner-status column with containment recorded as
+*proposed* and authentication/assurance evidence as *declined* with flex-auth's
+reasoning, all three consistency defects fixed, and both T05 answers folded into
+`approval-engine`'s INTENT and `GH-WP-0002-T06`. gate-house also recorded
+plainly that v0.4 had ruled against shipped assented behavior and that neither
+it nor ops-warden caught it. That is the loop working.
+
+## Disposition
+
+**Assent to v0.6 and companion v0.1**, with two answers and five findings. None
+blocks adoption.
+
+The Engine typing in §3.3 is a real improvement and flex-auth endorses it,
+particularly *"a new engine is a PIP unless this standard is amended"* — that
+sentence is the structural form of §6, and it forecloses the drift §6 was
+written to prevent.
+
+### Answer to question 1 — §6.4.2, no local recaching of the verdict
+
+**The rule is right and flex-auth supports it.** Caching the answer is deciding
+early at the consumer; caching an input claim under its own freshness rule is
+not. Three refinements, one of which is a genuine collision:
+
+**(a) It contradicts §9.7.1 as written.** §9.7.1 permits an allow bound to *"a
+session or obligation that ends."* A session-bound allow is used across later
+requests by construction — that is what binding to a session means. §6.4.2
+forbids replaying a stored verdict *"for a later request."* Taken together, a
+session-bound allow is both permitted and prohibited. The fix is small: scope
+§6.4.2 to requests **outside the decision's own stated binding and lifetime**,
+which preserves the rule and legalizes exactly the case §9.7.1 already intends.
+
+**(b) "Later request" needs a mechanical test, and flex-auth already ships one.**
+A PEP retrying an identical action after a transport failure is not a later
+request, but nothing in the standard says how to tell. flex-auth computes a
+canonical request digest over the normalized subject, action, resource, and
+context (`NewDecisionBinding`, `FLEX-WP-0017-T01`), and it is already in every
+decision binding. flex-auth offers it as the normative test: **replay is
+permitted iff the request digest matches and the decision's lifetime holds.**
+That makes §6.4.2 checkable rather than a matter of implementer judgment, and it
+costs the estate nothing new.
+
+**(c) Deny-caching is the one real pattern the rule outlaws without naming it.**
+A consumer caching a *deny* under load cannot manufacture authority — §8's
+asymmetry holds, and it protects the PDP from retry storms, which is a real
+operational need. But it does breach §6.4.4: an action refused with no decision
+record naming that request is not reconstructable, and a stale deny is an
+availability failure that will be misdiagnosed as a policy one. flex-auth's
+recommendation is to **rule on it explicitly** rather than leave implementers to
+infer: permit short-lived negative caching only where the refusal is still
+recorded, or forbid it in terms. Either is defensible; silence is not, because
+this is the pattern an implementer under load reaches for first.
+
+### Answer to question 2 — §9.7.2, does the visibility deadline land on a PDP
+
+**Yes, and it lands harder on the PDP than on the PEP** — but one number is the
+wrong shape for a decision point.
+
+A PEP has one boundary and can state one deadline. A PDP's revocation visibility
+is **per input class**, because a decision is a join over sources with unrelated
+refresh behavior: approval-claim freshness from `approval-engine`, registry
+snapshot cadence, policy package activation, and directory ETag. A single
+flex-auth number would be either a fiction or the worst case, and the worst case
+is the registry snapshot — which is the slowest and the least visible. Proposed:
+**§9.7.2 requires a per-input-class deadline at a PDP and a single boundary
+deadline at a PEP.**
+
+The consequence for flex-auth is worth stating plainly, because it changes
+flex-auth's own priorities. §9.7.2 makes the self-declared registry-provenance
+gap **load-bearing rather than untidy**. Without a snapshot digest in
+`DecisionProvenance`, nobody can determine after the fact which snapshot a
+decision read, so a stated visibility deadline for registry-borne facts is
+unfalsifiable — the deadline and the digest are the same gap seen from two
+sides. flex-auth accepts that this raises the gap from housekeeping to a
+conformance prerequisite and will plan it as one.
+
+### Finding 1 — §6.4's stance-map register does not exist
+
+§6.4 requires every PEP-shaped consumer to publish its stance map and requires
+those maps to be *"inventoried — in `maturity-engine` once it exists, in §13
+until then."* **§13 contains no stance rows and does not mention stance maps.**
+Neither document says where a map is published or in what form.
+
+This matters for precisely the reason §6.4 gives: without the register,
+*"`z0`–`z2` and unknown fail open"* is the estate's effective policy with nobody
+having compiled it. `ops-warden` `ADR-0009` is cited three times across the two
+documents as the reference shape and appears in no register. flex-auth has a
+direct interest here — the aggregate of consumer stances is the estate's real
+authorization behavior, and flex-auth is the only repository positioned to
+notice when it diverges from what the policy packages say.
+
+### Finding 2 — the companion omits it too, which answers the question asked
+
+gate-house asked what would show the companion is not sufficient on its own.
+Companion §5.3 says *"publish your unreachable-engine stance"* but never says
+**where**, and omits the inventory obligation entirely. A repository satisfying
+the companion faithfully would publish a stance map into its own repo and
+believe itself conforming, and no register would learn of it. On every other
+point reviewed the companion is faithful to the statute; this is the one gap.
+
+### Finding 3 — §17 puts the decision-record schema in the wrong layer
+
+The four artifacts are the right four, and Taxonomy is right for three of them.
+The **request-claim schema** is genuinely cross-engine vocabulary and belongs
+there; so do the gap-record and emission-cadence artifacts.
+
+The **decision-record schema** does not. A decision record is the PDP's output
+artifact — the one thing in the estate that only `access-engine` produces — and
+§2 keeps what a repository owns in that repository's own `INTENT.md`. flex-auth
+already publishes its shape: the `binding` in `DecisionEnvelope`, the request
+digest, and `schemas/action_authorization.schema.json`. Taxonomy authoring the
+schema for an artifact only flex-auth emits inverts the ownership rule the
+standard applies everywhere else.
+
+This is the same §2 argument flex-auth used to decline authentication and
+assurance evidence in `FLEX-DEC-2026-002`, and gate-house accepted it there.
+Symmetry requires flex-auth to apply it against its own interest as well as for
+it: proposed split is **claim / gap-record / emission-cadence to Taxonomy,
+decision-record schema to `access-engine` as a published contract**, with
+Taxonomy holding only the shared field vocabulary the claim schema needs to
+reference. flex-auth will publish that contract; it should not receive it.
+
+### Finding 4 — §§17–19 are H1, outside the section hierarchy
+
+They use `#` where every other section uses `##`, so they render as siblings of
+the document title rather than sections of it. Mechanical, but the standard asks
+repositories to cite section numbers, and §§17–18 carry normative content.
+
+### Finding 5 — §19 grades the document it lives in
+
+A *"Verdict on fitness"* inside a standard of record makes the assessment
+normative by adjacency and will age against the text it grades — v0.7 will
+either restate it or leave a stale verdict in force. Suggest it live in the
+2026-08-29 assessment history document and be cited from §16, where the open
+questions already carry the same content as questions rather than as a grade.
+
+## Consequences
+
+- flex-auth's assent attaches to **v0.6 + companion v0.1**, with §6.4.2 and
+  §9.7.2 read as refined above pending gate-house's disposition.
+- The registry-snapshot digest gap is reclassified from housekeeping to a
+  conformance prerequisite under §9.7.2, and will be planned as one.
+- flex-auth offers the canonical request digest as the §6.4.2 replay test and
+  offers to publish the decision-record schema as its own contract.