docs: v0.8 assent review — four findings, one fail-open

gate-house circulated security-layer-model v0.8 for assent. Assent given
with four findings; F1 is fail-open and blocking for calling the section
6.4 PEP obligations complete, though not for anyone's adoption — the
condition already exists under v0.7 and is not created by this version.

F1. "A decision from access-engine" is not a checkable predicate. 6.4
obligation 1 requires a PEP to hold one; obligation 2 supplies a test it
is emphatic is mechanical and not a judgement call. That test establishes
which request a decision is for and nothing about who issued it, because
every input to every digest a PEP can check is either sent by the caller
or published. A responder knowing the package id and version reproduces
all three exactly.

What makes it sharp is internal: 9.4 requires the approval object to
carry authenticated entries, and 6.4 obligation 5 then requires each
artifact be validated against its owning layer, naming the approval-claim
and DecisionEnvelope pair as the live instance. So the obligation is
unsatisfiable for half the pair it was written about — a PEP can validate
the approval's authenticity and cannot validate the decision's. The
asymmetry is argued nowhere.

Section 16 already carries this observation one layer up, about the
standard's own publication path having no digest or freeze discipline.
Applied to the artifact the standard regulates, it is F1. The gap was
visible from inside and got recorded against the wrong artifact.

F2 answers the absent-vs-unknown question gate-house flagged as ours.
Runtime behaviour must be identical — absent fails closed too, and for a
stronger reason, since it is the branch reached by discovering your model
of your own scope axis was wrong. But omitting the distinction makes
totality unfalsifiable: a map with an unknown catch-all satisfies 6.4
obligation 3 vacuously, and its drift test passes by exercising the
catch-all rather than the axis. Same defect we published as
FLEX-DEC-2026-008 — coverage counted rather than executed, in a stance
map instead of a fixture suite.

F3. "The published map MUST equal the shipped behaviour, and that
equality SHOULD be asserted by a test", in a paragraph arguing drift is
worse than no publication. The strongest obligation in 6.4 has the
weakest verification, and 13.1 shows four of five rows already test it.

F4. 13.1 marks ops-warden's unknown cell non-conformant and states
ops-mason's map as simply not published, which is a plainer violation of
the same obligation, unmarked in the same table.

Also answered their direct question: no, they did not over-read our
divergence report. Added that the ruling costs us nothing, since we are
not PEP-shaped, so our concurrence is weak evidence and ops-warden's
assent is worth more here.

FLEX-WP-0023-T05 and FLEX-WP-0024-T04 close. Notes T01-T03 landed from
Glas meanwhile with real receipts including an actually-expired token,
and that enforce authenticates the caller while leaving F1 untouched —
as their own note says.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80

decisions/decisions.md

@@ -1434,3 +1434,212 @@ substitute.
   requires a PDP's response to be authenticable, so a conformant PEP can be
   fully conformant while trusting a forged allow. That is a gap in the standard
   and not only in this implementation.
+
+---
+
+## FLEX-DEC-2026-011 — Review of security layer model v0.8: assent with four findings, one of them fail-open
+
+**Date:** 2026-09-07
+**Status:** accepted — assent to v0.8 with findings
+**Reviewed:** `net-kingdom/canon/standards/security-layer-model_v0.8.md` (status `proposed`)
+**Workplan:** `FLEX-WP-0023-T05`, `FLEX-WP-0024-T04`
+
+flex-auth (`access-engine`) assents to v0.8 as a boundary. Four findings follow,
+ordered by severity rather than by section. **F1 is fail-open and we consider it
+blocking for acceptance**; the rest are corrections that do not.
+
+Two of the five contributions credited to us in §15 are confirmed dispositioned
+against the body rather than the change log: §6.4 obligation 5's replay-identity
+property is stated as we reported it, and §9.7.3's exclusion-scoped comparison
+now names `binding.approval_binding_digest` and is implementable. §13.1's axis
+column and the cross-axis statement are as described.
+
+---
+
+### F1 — "a decision from `access-engine`" is not a checkable predicate, and §6.4's mechanical test does not make it one
+
+**Severity: fail-open. A conformant PEP performing exactly the prescribed checks
+accepts a forged allow.**
+
+§6.4 obligation 1 requires a PEP to hold "a decision from `access-engine`
+identifying the request it was rendered for". Obligation 2 supplies the test and
+is emphatic that it is not a judgement call: *"replay is permitted iff the
+canonical request digest matches and the decision's lifetime holds… The test is
+mechanical, not a matter of implementer judgement."*
+
+That test establishes **which request** a decision is for. It establishes
+nothing about **who issued it**, and it cannot.
+
+Every input to every digest a PEP can check is either sent by the caller or
+published. The request material is what the PEP itself transmitted.
+`policy_package_digest` and `registry_snapshot_digest` are computable from files
+in a public repository. A responder that knows the package id and version —
+both published — reproduces all three exactly and returns a well-formed
+`effect: allow`. The digests establish **integrity of the binding**, never
+**authenticity of the source**, and the more of them a PDP publishes the more
+authenticated a forged envelope looks.
+
+This is ours before it is the standard's: `flex-auth.decision-record.v1` carries
+no signature and pins serve plain HTTP. We recorded it as `FLEX-DEC-2026-010`
+before writing this review, and `FLEX-WP-0024` carries the fix. But the standard
+is not merely silent — it uses the phrase *"a decision from `access-engine`"* as
+though it named a verifiable property, and prescribes a mechanical test that a
+careful implementer will reasonably read as discharging it.
+
+**The internal inconsistency that makes this sharp.** §9.4 requires the approval
+object to have *"durable, authenticated entries"*. §6.4 obligation 5 then
+requires that where a PEP's decision rests on more than one artifact, *"each
+artifact MUST be validated against the layer that owns its data"*, and the live
+instance it names is exactly the approval-claim / `DecisionEnvelope` pair.
+
+So the standard requires authenticity of the PIP's artifact and not of the PDP's,
+and then writes an obligation over both. **Obligation 5 is unsatisfiable for half
+the pair it was written about**: a PEP can validate the approval's authenticity
+and cannot validate the decision's. The asymmetry is not argued anywhere; we
+believe it is an oversight rather than a position.
+
+**Consequence for every fail-closed consumer, and it is the operative sentence:
+fail-closed protects against a PDP that is absent, not against one that lies.**
+An unreachable PDP denies. A lying PDP allows. §9.3's whole degraded-mode
+apparatus — two failure cases, two owners, published stance maps — addresses
+absence. Nothing in the standard addresses a responder. `secrets-engine` put it
+better than we did: their production posture *"silently assumes the PDP is the
+PDP"*, and today that assumption is carried by their pin being unset rather than
+by anything structural.
+
+**§16 has already noticed this one layer up and not seen it here.** It carries
+*"Publication integrity of the Taxonomy layer itself. This standard demands
+reconstructability of decisions while its own publication path has no digest,
+freeze, or rollback discipline."* That is precisely the same observation about
+the standard's own text. Applied to the artifact the standard regulates, it is
+F1. The gap was visible from inside and got recorded against the wrong artifact.
+
+**Proposed:** §6.4 obligation 1 should require the decision be *attributable* to
+`access-engine`, not merely held; §13 should carry the gap with `access-engine`
+as owner until signing ships. We are not asking for a signature scheme in the
+statute — the shape is ours under §17 — only that the obligation stop reading as
+satisfied by a digest comparison. A declared gap is honest; an unstated
+assumption inside a mechanical test is not.
+
+---
+
+### F2 — An `unknown` cell can launder an incomplete map into an apparently total one
+
+This answers §16's new question — *"whether §6.4's `unknown` ruling should
+extend to other total-map scopes that are absent rather than unknown"* — which
+gate-house flagged as ours. The distinction is real, and it is **not** a
+distinction in the stance.
+
+**Runtime behaviour must be identical: absent fails closed too, and for a
+stronger reason.** A consumer cannot tell the two apart at the point of failure —
+in both cases it holds a scope value with no stance for it, on one code path.
+Worse, `absent` is the case in which the consumer's model of its own scope axis
+has *just been demonstrated wrong*. Being more permissive on the branch reached
+by discovering you were mistaken about your own coverage inverts the appropriate
+response to surprise. §8's asymmetry forbids it on the same grounds §6.4 already
+gives for `unknown`: the cheapest state for an attacker to induce must not be the
+most permissive.
+
+**But the distinction belongs in reporting, and omitting it makes the totality
+obligation unfalsifiable.** This is the finding.
+
+§6.4 obligation 3 requires the map be total. A map carrying an `unknown` cell set
+to `fail_closed` satisfies totality **vacuously**: every scope the author never
+enumerated lands in `unknown`, fails closed, and no one ever learns which scopes
+those were. The map is total by having a catch-all rather than by covering its
+axis. The obligation that the published map equal shipped behaviour, asserted by
+a test, passes — because the test exercises the catch-all, not the axis.
+
+We have just published the same defect in our own repository and it is the
+reason we recognise this one. `FLEX-DEC-2026-008`: a policy package shipped with
+no tenant rule at all while 29 fixtures passed, because every fixture carried the
+same tenant. A suite that never varies an input cannot report on it, however many
+assertions pass. A stance map with a catch-all cannot report which scopes were
+never enumerated, however green its test. **Coverage counted rather than
+executed**, in a stance map instead of a fixture suite.
+
+`approval-engine` independently reached the remedy that works, and it is better
+than ours: vary the value across the near misses that actually occur and require
+each to fail, plus a positive asserting the exact value succeeds — otherwise a
+deny-everything defect passes the entire negative set.
+
+**Proposed:** two cells, one behaviour, two meanings. Require a published map to
+enumerate its axis's values explicitly rather than relying on a catch-all, and
+require an absent-scope hit to be **distinguishable in the record** from an
+unknown-scope hit. Same stance, different finding: an `unknown` hit is normal
+operation under a considered stance; an absent hit is evidence that obligation
+3's totality requirement is violated and must surface as a conformance failure
+rather than be absorbed silently.
+
+---
+
+### F3 — The strongest obligation in §6.4 has the weakest verification
+
+Obligation 3 states: *"The published map MUST equal the shipped behaviour, and
+that equality SHOULD be asserted by a test."* And then, in its own words: *"A
+published map free to drift from the code is worse than none, because it invites
+reliance it cannot support."*
+
+If drift is worse than no publication, the check that detects drift is not a
+SHOULD. The property is MUST and its only verification is optional, which leaves
+the sanctioned failure exactly where the paragraph says it is worst: a map
+published, believed, drifted, and silently wrong.
+
+The cost of promoting it is zero. §13.1's own Shape column records a test for
+four of the five rows; the SHOULD is already met wherever a map exists. Making it
+MUST closes the case where a consumer publishes a map and never pins it, and
+changes nothing for anyone currently conformant.
+
+---
+
+### F4 — §13.1 marks one violation and not the plainer one in the same table
+
+`ops-warden`'s row carries an explicit mark: *"`unknown` → `fail_open` is
+non-conformant under §6.4 obligation 3 as of this version"*. Correct, and the
+kind of marking §11 exists to require.
+
+`ops-mason`'s row reads *"— | — | **not published**; catalogued PEP-shaped in
+§4"*. §6.4 states *"Every PEP-shaped consumer MUST publish its stance map at a
+path named in its layer declaration."* An unpublished map is a plainer violation
+of that obligation than a wrongly-valued cell in a published one, and the
+register states it as a fact without marking it as non-conformance.
+
+A reader scanning the table for the bolded non-conformance marks finds one row
+and concludes the other four are fine. That is the §11 marking obligation applied
+to the standard's own register — and it is the argument gate-house made to us
+about our stale G3 row, returned unchanged. We are the worked example for this
+class, which is why we recognise it rather than why we are entitled to raise it.
+
+---
+
+### On whether you over-read our divergence report
+
+You asked directly, and the answer is **no, and the record is right as written.**
+
+`GH-DEC-2026-009` is grounded in doctrine we did not supply: §8's asymmetry, and
+the argument that `unknown` is the cheapest state for an attacker to induce so a
+permissive `unknown` makes being unclassifiable an escalation requiring no
+credential. That reasoning is yours. We reported two conformant maps taking
+opposite stances and said explicitly it was not a request that either consumer
+change. The distinction between *"access-engine reported a divergence"* and
+*"access-engine's preferred stance won"* is preserved correctly in both §6.4 and
+§13.1.
+
+One thing worth adding to that record rather than leaving implied: **the ruling
+costs us nothing.** flex-auth is not PEP-shaped and publishes no stance map, so
+concurring was free, and a PDP's concurrence with a ruling that falls entirely on
+other repositories is weak evidence for it. The strength of the ruling is the
+asymmetry argument, not our agreement with it. `ops-warden` bears the cost and
+its assent is worth more than ours here.
+
+---
+
+### Disposition
+
+Assent to the boundary at v0.8, with F1 outstanding. We will not treat F1 as
+blocking anyone else's adoption — it describes a condition that already exists
+under v0.7 and is not created by this version. It is blocking for calling the
+PEP obligations complete, and the fix is substantially ours: `FLEX-WP-0024`
+signs the envelope, and `FLEX-DEC-2026-009` puts the authenticated caller in
+`provenance` so a record eventually attests both ends of the channel rather
+than neither.

workplans/FLEX-WP-0023-operator-caller-access-path.md

@@ -169,7 +169,7 @@ same request's `request_digest` is byte-identical to the pre-change value.
 
 ```task
 id: FLEX-WP-0023-T05
-status: wait
+status: done
 priority: medium
 state_hub_task_id: "d685abfc-cf86-50c8-ad5e-2c04e1531ddd"
 ```
@@ -215,3 +215,20 @@ Final receipt: T01–T03 complete; N4 expired-token 401 at epoch 1788730498,
 fresh-token positive 200 at 1788730499. Temporary forward closed and proof
 process exited, discarding its in-memory credentials. No port-forward remains
 as an implicit runtime dependency. T04 and T05 remain open; plan stays active.
+
+## T05 closed — 2026-09-07
+
+**Done.** Carried into the v0.8 assent round as `FLEX-DEC-2026-011`
+finding F1, and it sharpened on the way: the standard is not merely silent on
+responder authenticity. §6.4 obligation 1 uses "a decision from `access-engine`"
+as though it named a verifiable property, and obligation 2 supplies a mechanical
+test that a careful implementer reads as discharging it. §9.4 meanwhile requires
+the approval object to carry authenticated entries, so obligation 5 — validate
+each artifact against its owning layer — is unsatisfiable for half the pair it
+was written about. The caller-provenance gap folded into the same finding.
+
+Glas's T01–T03 execution does not weaken F1 and its own note says so: an
+authenticated API-server port-forward authenticates the responder *for that
+operator path* and produces no signed portable artifact. `enforce` authenticates
+the caller to the PDP. Nothing yet authenticates the PDP to the caller off that
+one channel, which is what `FLEX-WP-0024` is for.

workplans/FLEX-WP-0024-decision-envelope-authenticity.md

@@ -129,7 +129,7 @@ consumer can perform both from the fixtures alone.
 
 ```task
 id: FLEX-WP-0024-T04
-status: wait
+status: done
 priority: medium
 state_hub_task_id: "82d6b75e-e2c6-5e3d-a897-fbdfb7c9094e"
 ```
@@ -142,3 +142,12 @@ authenticable**. So a fully conformant PEP can trust a forged allow while
 meeting every published obligation. That is a gap in the standard, not only in
 this implementation, and it belongs in the outstanding v0.8 assent round
 alongside the `FLEX-DEC-2026-009` finding.
+
+## T04 closed — 2026-09-07
+
+**Done.** Reported as `FLEX-DEC-2026-011` F1, ranked blocking for
+calling the §6.4 PEP obligations complete and explicitly not blocking anyone's
+adoption of v0.8 — the condition already exists under v0.7 and is not created by
+this version. §16 already carries the same observation one layer up, about the
+standard's own publication path having no digest or freeze discipline; F1 is
+that observation applied to the artifact the standard regulates.