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

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.