Record GH-DEC-2026-005 in the claim contract itself

The ruling names docs/approval-claim.md as the step-1 artifact on the
GH-DEC-2026-003 path, but the contract did not say so. It listed only
access-engine as consumer, so an implementer reading the governed
artifact alone would not learn that PEP-shaped consumers read it as step
1, that no other envelope may be served from that endpoint, or that a PEP
validates across this claim and the step-2 DecisionEnvelope.

State the two-artifact split and the layer rule at the top, and state
that the approval fact's authority is this engine -- a consumer requiring
a state-hub authority fails closed against every correctly issued
response, which is the defect GH-DEC-2026-005 struck. Point both
consumers at the existing Required verification section.

Also update the request doc's trailing record block from proposed to
resolved with its decision id, so a reader copying it does not
reintroduce a pending record for a settled question.

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/approval-claim.md

@@ -3,12 +3,28 @@
 **Schema:** [`../schemas/approval_claim.schema.json`](../schemas/approval_claim.schema.json)
 **Version:** 0.1
 **Issuer:** `approval-engine`
-**Consumer:** `access-engine` (`flex-auth` until the governed rename)
+**Consumers:** `access-engine` as PDP (`flex-auth` until the governed rename);
+PEP-shaped consumers as step 1 of the `GH-DEC-2026-003` consumption path
 
 This is the input claim `access-engine` consumes under statute §6.2. It is a
 fact about an approval object. It is **not a decision**. An implementer can
 satisfy this document without reading this engine's source.
 
+**This is the step-1 artifact.** `GH-DEC-2026-005` (2026-09-06) confirms that
+`GET /v1/approvals/{id}/claim` serves this claim on the `GH-DEC-2026-003` path,
+that no other envelope is required or may be served from this endpoint, and
+that a PEP validates across **two** artifacts: this claim for the approval
+fact, and the step-2 flex-auth `DecisionEnvelope` for exact `CheckRequest`
+match and the policy package/version pin. Each artifact is validated against
+the layer that owns its data; a PIP does not republish the PDP's decision. The
+"Required verification" section below is the supported path for both consumers.
+
+The authority for the approval fact is this engine — `issuer:
+"approval-engine"`. State Hub is a read model and issues no approval; a
+consumer requiring a `state-hub` authority on this claim fails closed against
+every correctly issued response. `GH-DEC-2026-005` struck that requirement
+explicitly.
+
 Yields to the Taxonomy request-claim schema (statute §17) when that artifact
 exists and is assented. This local shape is not permanent.
 

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

@@ -135,12 +135,16 @@ 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
+## Record as resolved
+
+Adopted by gate-house as `GH-DEC-2026-005`; this block reflects the outcome,
+not the original request.
 
 ```yaml
+id: GH-DEC-2026-005
 kind: decision
 title: The approval-claim is the step-1 artifact on the PEP consumption path
-status: proposed
+status: resolved
 owner: Bernd Worsch
 repo: gate-house
 standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
@@ -149,6 +153,7 @@ requested_dispositions:
 - approved
 - revised
 - rejected
+disposition: approved
 affects:
 - gate-house
 - approval-engine