Confirm the approval-claim as the step-1 PEP artifact

approval-engine raised APPROVAL-IN-0002: secrets-engine's PEP validator
expects a flex-auth ActionAuthorization but fetches the approval-claim
endpoint that GH-DEC-2026-003 names as step 1. Two objects on one path.

GH-IN-0002 records the intake; GH-DEC-2026-005 resolves it. The claim is
the step-1 artifact and always was — ActionAuthorization is unratified,
has no valid_now field, and cannot be served from a step-1 call. The
addition beyond confirmation is doctrine: a PEP validates each artifact
against the layer that owns its data, and no PIP republishes the PDP's
decision. The provenance.authority == "state-hub" requirement is struck;
State Hub is a read model and holds no runtime approval authority.

docs/contracts/approval-consumption.md carries the amendment at the
sequence itself so implementers find it there.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 425128@bnt-lap001
Assistant-Session: f5944d8b-dac4-4e1a-87eb-8b3d8f314a63
This commit is contained in:
tegwick 2026-09-06 01:29:28 +02:00
parent 60e2e7de65
commit 1a920a5490
3 changed files with 115 additions and 3 deletions

View file

@ -3,8 +3,9 @@
**Owner:** gate-house
**PIP:** approval-engine
**PDP:** access-engine (currently flex-auth)
**Status:** normative for GH-WP-0002-T06; recorded as `GH-DEC-2026-003`
**Date:** 2026-08-29
**Status:** normative for GH-WP-0002-T06; recorded as `GH-DEC-2026-003`,
amended by `GH-DEC-2026-005` (step-1 artifact and split validation)
**Date:** 2026-09-06
**Statute:** `net-kingdom/canon/standards/security-layer-model_v0.7.md` §9.4, §9.7.34, §16
**Blocks:** `APPROVAL-WP-0001-T05`, `FLEX-WP-0017-T05`
@ -30,6 +31,35 @@ companion §5 already treats as PEP-shaped.
Holding a claim with `valid_now: true`, or an ALLOW against that claim, is not
authority to act. The consume is.
## What each step's artifact is
Amended by `GH-DEC-2026-005`.
**Step 1 serves the approval-claim** (`approval-engine/docs/approval-claim.md`).
That is the artifact `valid_now` belongs to, and it is the only object the claim
endpoint serves. flex-auth's proposed `ActionAuthorization` is **not** required
here, is not served here, and MUST NOT be served from this endpoint: a step-1
response cannot contain a step-2 decision.
**A PEP validates across both artifacts it already fetches**, and each against
the layer that owns its data:
| Artifact | Source | What the PEP checks |
| --- | --- | --- |
| approval-claim | step 1, `approval-engine` (PIP) | binding digest, validity window, consumption state, observation freshness, issuer |
| `DecisionEnvelope` | step 2, `access-engine` (PDP) | exact `CheckRequest` match, policy package and version pin |
A PIP MUST NOT republish the PDP's decision, and a PEP MUST NOT accept the
approval fact from the decision artifact or the decision from the approval
artifact. Composing the two into one served object is a separate, post-decision
artifact at a separate endpoint if it is ever ratified — not a change to the
claim.
**Claim provenance is not State Hub.** A PEP MUST NOT require
`provenance.authority == "state-hub"` on the claim. State Hub is a read model and
holds no runtime approval authority; the issuer to check is the engine that
served the claim.
## Why consume is before the side effect
§9.7.3 says consumption MUST NOT be inferred from a decision record. That