Accept ActionAuthorization deferral; fix the state-hub authority constant

approval-engine filed APPROVAL-IN-0002: secrets-engine built its PEP
validator against our ActionAuthorization schema, pointed it at
GET /v1/approvals/{id}/claim, and it rejects every response. Both
envelopes declare schema_version 0.1, so it fails late and reads like an
approval-engine outage rather than a contract mismatch.

FLEX-DEC-2026-006 accepts the deferral and argues against flex-auth's own
proposal. The composed object had the PIP republish our decision, which
crosses the same layer boundary we invoked to decline authentication
evidence and to win section 17's schema. The claim-plus-DecisionEnvelope
split drops no check; each verification lands on the layer that owns it.

approval-engine asked, before the decision, whether the open G3 finding
argues for ratifying now. It does not: G3 is already closed the other
way. FLEX-WP-0019 added lifetime to the DecisionEnvelope itself, required
on every allow by schema conditional, published 2026-09-02. The trigger
resolved by adding a field rather than by composition, so the decision
stands alone and needs no bundle.

The provenance.authority == state-hub constant is our defect and is
fixed at source. It came from examples/caring/action_authorization.json,
which contradicted the same contract's ownership section. That fixture
now names approval-engine as the approval fact's authority and flex-auth
as the decision's, and its stale secrets-engine.lifecycle pin is
corrected to the reserved coordinate from FLEX-DEC-2026-005.

The contract doc and schema are marked deferred-not-withdrawn so no
other consumer builds a validator against them. The execute-time half is
untouched: /v1/check, binding, the canonical digest, and
flex-auth.decision-record.v1 stay published.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19

docs/action-bound-authorization-contract.md

@@ -1,9 +1,11 @@
 # Action-bound authorization contract
 
-Status: implemented for execute-time request binding; durable approval storage
-and lifecycle require `approval-engine` support.
+Status: **execute-time request binding is implemented and published.** The
+composed `ActionAuthorization` object in this document is **deferred, not
+withdrawn** — see "Deferral of the composed object" below. Do not build a
+validator against it.
 
-Date: 2026-08-23
+Date: 2026-08-23 (deferral recorded 2026-09-06, `FLEX-DEC-2026-006`)
 
 ## Ownership and endpoints
 
@@ -30,7 +32,28 @@ decision records are coordination and provenance evidence; they are not the
 runtime approval authority. Production consumers must not infer action binding
 or dual control from State Hub prose or a free-form `decided_by` value.
 
-## Durable object
+## Deferral of the composed object
+
+`ActionAuthorization` was never ratified. `GH-DEC-2026-003` (2026-08-29) named
+`approval-engine`'s **approval-claim** as the step-1 artifact, and flex-auth
+accepts that split (`FLEX-DEC-2026-006`):
+
+- **Step 1 — approval fact:** `approval-engine`'s approval-claim, served from
+  `GET /v1/approvals/{id}/claim`. `approval-engine` is its authority.
+- **Step 2 — decision:** flex-auth's `DecisionEnvelope`, with exact
+  `CheckRequest` match via `binding.request_digest` and the policy pin.
+
+A PEP validates **across both**. No check from the composed object is dropped;
+each one lands on the layer that owns it. The composed object would have had
+the PIP republish flex-auth's decision, which is the part that was wrong.
+
+The `PROPOSED` framing below is retained as the record of what was proposed.
+It is not a contract, and a consumer that validates a `GET /v1/approvals/{id}/claim`
+response against it will reject every response — both envelopes declare
+`schema_version: 0.1`, so the mismatch surfaces late and reads like an
+`approval-engine` outage. That is exactly what happened to secrets-engine.
+
+## Durable object (deferred — proposed, never ratified)
 
 [`../schemas/action_authorization.schema.json`](../schemas/action_authorization.schema.json)
 defines the proposed `ActionAuthorization` storage and transport object. It
@@ -80,6 +103,14 @@ A production consumer may execute only when all of the following hold:
 Local fixtures, CCR labels, workplan ids, prose, and a caller-supplied flex-auth
 decision id are provenance only. They cannot unlock a production action.
 
+**State Hub is never the authority here.** A validator must not require
+`provenance.authority == "state-hub"`, or accept it as evidence. State Hub
+decision records are coordination and provenance evidence, as the Ownership
+section above states. The authority of the approval fact is `approval-engine`;
+the authority of the decision is flex-auth. The stale `"authority": "state-hub"`
+value in `examples/caring/action_authorization.json` was the source of that
+constant and is corrected.
+
 ## Outage and supersession semantics
 
 - `approval-engine` unreachable: privileged live