Draft the gate-house decision request on the claim envelope

secrets-engine's PEP validator expects a flex-auth ActionAuthorization
but calls the governed claim endpoint. Research shows this is a
confirmation rather than a redesign: GH-DEC-2026-003 already names
GET /v1/approvals/{id}/claim as step 1 by endpoint and by field
(valid_now, which ActionAuthorization does not have), and
ActionAuthorization appears zero times in gate-house and state-hub. It
originates in flex-auth's own doc, which calls it a *proposed* shape for
the durable approval object that the same doc assigns to approval-engine.
Its required authority == state-hub also contradicts flex-auth's prose
that State Hub is not the runtime approval authority.

Request asks gate-house to confirm the claim is the step-1 artifact and
that ActionAuthorization is not required there, with PEPs validating
across the claim and the step-2 DecisionEnvelope they already fetch. No
safety property is lost; each check returns to the layer owning the data.

Records a ratified post-decision ActionAuthorization as a deferred option
with explicit revisit triggers, plus the constraint that such an object
cannot be served from the step-1 call, so it is not rediscovered later.
Also records why serving it at the claim endpoint and additively
extending the claim were rejected.

Files APPROVAL-IN-0002 to track the request. 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

docs/gate-house-decision-request-claim-envelope.md

@@ -0,0 +1,138 @@
+# Decision request to gate-house — the claim envelope on the PEP path
+
+**Requested by:** approval-engine
+**Date:** 2026-09-06
+**Governs:** `GH-DEC-2026-003` (approval consumption ordering)
+**Blocks:** first live consume for `SECRETS-WP-0007-T04`; recorded on
+`APPROVAL-WP-0002-T05`
+**Does not block:** `APPROVAL-WP-0002-T03` (see "Scope" below)
+
+This is a drafted request, not a decision. gate-house owns the outcome.
+
+## The question
+
+secrets-engine's PEP validator (`validate_action_authorization`) expects an
+`ActionAuthorization` envelope, but calls
+`GET /v1/approvals/{id}/claim`, which serves approval-engine's approval-claim.
+The two are different objects. Which one is the step-1 artifact on the governed
+PEP path?
+
+## Why this is a confirmation, not a redesign
+
+`GH-DEC-2026-003` already names step 1 by endpoint and by field:
+
+```text
+1. PIP  GET /v1/approvals/{id}/claim  → valid_now (a fact, not permission)
+```
+
+`valid_now` is an approval-claim field. `ActionAuthorization` has no `valid_now`.
+
+`ActionAuthorization` is not a governed object. It appears zero times in
+gate-house and zero times in state-hub. It originates in flex-auth's
+`docs/action-bound-authorization-contract.md` (2026-08-23), whose own status
+line calls it *"the **proposed** `ActionAuthorization` storage and transport
+object"* — a proposed shape for the durable approval object, which the same
+document assigns to approval-engine. It was never ratified, and
+`GH-DEC-2026-003` was issued six days later without it.
+
+One further conflict worth recording: the validator hard-requires
+`provenance.authority == "state-hub"`, while flex-auth's own contract states
+that State Hub decision records *"are not the runtime approval authority."*
+The constant contradicts the document it came from.
+
+## Requested disposition — confirm the claim (option A)
+
+Confirm that:
+
+1. The approval-claim (`approval-engine/docs/approval-claim.md`) is the step-1
+   artifact on the `GH-DEC-2026-003` path.
+2. `ActionAuthorization` is **not** required on the claim path, and
+   approval-engine is not expected to serve it there.
+3. A PEP validates across the two artifacts it already fetches: the claim for
+   approval fact (binding digest, validity window, consumption state,
+   freshness, issuer), and the flex-auth `DecisionEnvelope` from step 2 for
+   exact `CheckRequest` match and policy package/version pin.
+
+No safety property is dropped by (3). `ActionAuthorization` is a *bundle* of
+approval fact plus decision envelope; splitting validation returns each check
+to the layer that owns the data, rather than having the PIP republish the PDP's
+decision.
+
+### What changes if approved
+
+| Repo | Change |
+| --- | --- |
+| approval-engine | none — the claim schema stands as published |
+| secrets-engine | split `validate_action_authorization` into a claim check and a decision check; drop the `authority == "state-hub"` requirement |
+| flex-auth | acknowledge the proposed `ActionAuthorization` is shelved on this path (see "Deferred option" — it is not withdrawn) |
+| gate-house | record the confirmation against `GH-DEC-2026-003` |
+
+## Deferred option D — a ratified post-decision `ActionAuthorization`
+
+Recorded so it is not rediscovered. **Not** requested now.
+
+A single composed post-decision artifact — canonical UUID, lifecycle status,
+one complete `CheckRequest`, bounded validity, approval evidence, and the
+matching `DecisionEnvelope` — remains a coherent design. flex-auth's schema and
+its secrets-engine profile already exist as a starting point.
+
+**Why not now:** it needs a named issuer and lifecycle owner (nobody holds
+that today), and `GH-DEC-2026-003` already settles the sequence without it. The
+cost is months; the present problem is resolved by a confirmation.
+
+**Revisit if any of these appear:**
+
+- a third or fourth PEP-shaped consumer, where per-consumer two-artifact
+  validation starts duplicating logic worth centralizing;
+- 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;
+- 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.
+
+**Constraint on any future adoption:** such an object is post-decision by
+construction. It cannot be served from the step-1 claim call, because a step-1
+response cannot contain a step-2 decision. It would be a new artifact at a new
+endpoint, not a change to the claim.
+
+## Also considered and rejected
+
+- **approval-engine serves `ActionAuthorization` at the claim endpoint.**
+  Structurally impossible for step 1, per the constraint above, and it would
+  require asserting a `state-hub` authority that this engine does not hold.
+- **Additively extend the claim** with `approvals.required_count` / `entries`.
+  Publishing approver identities to consumers is a deliberate least-disclosure
+  non-goal, and it still would not satisfy `id`, `authority`, or `request`, so
+  the consumer's validator changes regardless.
+
+## Scope
+
+This does not gate `APPROVAL-WP-0002-T03`. secrets-engine is fail-closed until
+T03 and its own T04 both land; deploying publishes a URL and commits no one to
+an envelope. The question gates the first live consume, not the deployment.
+
+## Proposed record
+
+```yaml
+kind: decision
+title: The approval-claim is the step-1 artifact on the PEP consumption path
+status: proposed
+owner: Bernd Worsch
+repo: gate-house
+standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
+source_note: docs/contracts/approval-consumption.md
+requested_dispositions:
+- approved
+- revised
+- rejected
+affects:
+- gate-house
+- approval-engine
+- flex-auth
+- secrets-engine
+- ops-warden
+```