Record GH-DEC-2026-005; strike the spent G3 revisit trigger

Gate House confirmed all three requested dispositions as GH-DEC-2026-005
(GH-IN-0002, closed); flex-auth accepted as FLEX-DEC-2026-006. The
approval-claim is the step-1 artifact, ActionAuthorization is not
required and MUST NOT be served from the claim endpoint, and a PEP
validates across the claim and the step-2 DecisionEnvelope. Gate House
recorded the split as doctrine rather than convenience -- a PIP must not
republish the PDP's decision -- and struck the provenance.authority ==
state-hub requirement explicitly. This engine's claim schema is
unchanged.

Correct the deferred option D trigger list. The G3 trigger was written
conditional on G3 being settled by composition; flex-auth reports
FLEX-WP-0019 closed it by adding a lifetime field to DecisionEnvelope on
2026-09-02, so a decision now states its own end without borrowing
ActionAuthorizationValidity. That was the one structural thing the bundle
did that the split does not, so the trigger is not merely spent -- it
resolved against ratification. Struck with reasons; a future revisit
needs a fresh argument. The trigger came from a stale row in a dated
2026-08-29 review record that flex-auth does not rewrite.

Also record the root cause of the bad authority constant: it came from a
flex-auth fixture, not prose. A contract whose examples contradict its
prose will be implemented as its examples.

Close APPROVAL-IN-0002. Docs only; 84 tests pass.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 411227@bnt-lap001
Assistant-Session: d566f6d3-bcaf-43c3-bc5e-3ddd0f64b535
This commit is contained in:
tegwick 2026-09-06 01:36:03 +02:00
parent 54ced98b84
commit 564534dbcb
4 changed files with 61 additions and 8 deletions

View file

@ -70,7 +70,17 @@ republished to consumers. The consumer checks in
[`approval-claim.md`](approval-claim.md) ("Required verification") are the
supported validation path.
Reconciling the two envelopes is a cross-repo contract change under
`GH-DEC-2026-003`, not a unilateral edit here. Until it is decided, this engine
keeps serving the approval-claim shape and does not emit a `state-hub`
authority it does not have.
**Settled 2026-09-06 by `GH-DEC-2026-005`** (with `FLEX-DEC-2026-006`). The
approval-claim is the step-1 artifact; `ActionAuthorization` is not required on
this path and **MUST NOT** be served from the claim endpoint. A PEP validates
across two artifacts: the claim for the approval fact, and the step-2 flex-auth
`DecisionEnvelope` for exact `CheckRequest` match and the policy pin.
Gate House recorded the split as doctrine rather than as an implementation
convenience: each artifact is validated against the layer that owns its data,
and **a PIP MUST NOT republish the PDP's decision**. The
`provenance.authority == "state-hub"` requirement was struck explicitly — State
Hub is a read model holding no runtime approval authority, so a validator
requiring it fails closed against every correctly issued claim.
This engine's claim schema is unchanged by the ruling.

View file

@ -1,5 +1,9 @@
# Decision request to gate-house — the claim envelope on the PEP path
**Status:** RESOLVED 2026-09-06 — confirmed in full as `GH-DEC-2026-005`
(gate-house commit `1a920a5`; recorded there as `GH-IN-0002`, closed) and
accepted as `FLEX-DEC-2026-006` (flex-auth commit `74bfb3b`). All three
requested dispositions granted. Retained as the reasoning record.
**Requested by:** approval-engine
**Date:** 2026-09-06
**Governs:** `GH-DEC-2026-003` (approval consumption ordering)
@ -40,6 +44,15 @@ One further conflict worth recording: the validator hard-requires
that State Hub decision records *"are not the runtime approval authority."*
The constant contradicts the document it came from.
**Root cause, established after this request was filed:** the constant came
from a *fixture*, not from prose — `flex-auth/examples/caring/action_authorization.json`
ended with `"provenance": {"authority": "state-hub"}`. A consumer reading the
example rather than the paragraph gets the wrong constant, which is what
happened. flex-auth has corrected the fixture and marked both the contract and
`action_authorization.schema.json` as deferred with a do-not-build-a-validator
warning. Worth generalizing: a contract whose examples contradict its prose
will be implemented as its examples.
## Requested disposition — confirm the claim (option A)
Confirm that:
@ -87,9 +100,16 @@ cost is months; the present problem is resolved by a confirmation.
- a requirement for a single signed, forwardable authorization artifact
(offline verification, or an audit that must replay one object rather than a
join);
- resolution of flex-auth's open G3 finding — `DecisionEnvelope` carries no
lifetime — if that is settled by composition rather than by adding a lifetime
field to the envelope;
- ~~resolution of flex-auth's open G3 finding — `DecisionEnvelope` carries no
lifetime~~ — **SPENT, and it resolved against ratification.** `FLEX-WP-0019`
closed G3 by *adding the field*, not by composition: as of 2026-09-02
`decision_envelope.schema.json` requires `lifetime` whenever `effect` is
`allow`, sourced from the policy package's `allow_ttl` (15m engine default),
and `allow_ttl: none` yields a deny with reason `allow_lifetime_unstated`
rather than a standing grant. A `DecisionEnvelope` now states its own end
without borrowing `ActionAuthorizationValidity` — the one structural thing the
bundle did that the split does not. This trigger is closed and must not be
re-cited; a future revisit needs a fresh argument (`FLEX-DEC-2026-006`);
- assent of the statute §17 Taxonomy request-claim schema (`APPROVAL-IN-0001`),
which the approval-claim already declares it yields to. If Taxonomy lands
first, converge there and **do not** revive this separately.

View file

@ -32,7 +32,7 @@ state_hub_intake_id: "01a05ef0-a034-7ef8-bae1-45840392f40e"
id: APPROVAL-IN-0002
kind: intake
title: Confirm the claim envelope on the PEP consumption path
status: open
status: closed
origin: coordination
origin_ref: APPROVAL-WP-0002-T05
priority: high
@ -44,6 +44,15 @@ tags:
- cross-repo
created: '2026-09-06'
updated: '2026-09-06'
resolution: >-
Resolved 2026-09-06. Confirmed in full as GH-DEC-2026-005 (recorded at
gate-house as GH-IN-0002 and closed) and accepted as FLEX-DEC-2026-006. The
approval-claim is the step-1 artifact; ActionAuthorization is not required
and MUST NOT be served from the claim endpoint; PEPs validate across the
claim and the step-2 DecisionEnvelope. The provenance.authority ==
state-hub requirement was struck explicitly. approval-engine's claim schema
is unchanged. The deferred option D G3 revisit trigger is spent: G3 closed
by adding a lifetime field, not by composition.
description: >-
secrets-engine's PEP validator expects a flex-auth ActionAuthorization but
calls GET /v1/approvals/{id}/claim, which serves approval-engine's governed

View file

@ -197,3 +197,17 @@ governed approval-claim (`approval_id`, `state`/`valid_now`, `binding`,
rather than a version error. Recorded in `docs/approval-consumption.md`;
reconciling the envelopes is a `GH-DEC-2026-003` cross-repo change, not a
unilateral edit here. T05 stays `wait`: still no deployed base URL (T03).
2026-09-06 ruling: the claim-envelope question is settled. `GH-DEC-2026-005`
confirms all three requested dispositions — the approval-claim is the step-1
artifact, `ActionAuthorization` is not required and MUST NOT be served from the
claim endpoint, and a PEP validates across the claim and the step-2
`DecisionEnvelope`. Gate House recorded the split as doctrine (a PIP must not
republish the PDP's decision) and struck the `provenance.authority ==
"state-hub"` requirement explicitly. flex-auth accepted as `FLEX-DEC-2026-006`,
argued against its own proposal, and traced the bad authority constant to a
fixture rather than prose. **This engine changes nothing: the claim schema
stands as published.** `APPROVAL-IN-0002` is closed. T05 remains `wait` on T03
deployment plus the secrets-engine validator split and its
`secrets-engine-approval` KeyCape registration (already requested verbatim in
`docs/keycape-service-registrations.md`).