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

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:

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

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