GH-DEC-2026-005 moved the distinct-approver check off the PEP onto this
engine's valid_now. secrets-engine has implemented the split and reports
it no longer verifies the threshold independently. Gate House accepted
that as correct on layering AND as a genuine reduction in defence in
depth, and named the compensating control: not a second check at the PEP,
which is the duplication the split removes, but reconstructability at the
issuer under §9.6.
The emitted events could not support that. approval.issuance carried
required_count but never who satisfied it, and approval.use carried no
threshold evidence at all, so an auditor replaying the stream could not
recompute the evaluation without reading live rows -- rows that may since
have been superseded, revoked, or expired.
Both events now carry a threshold object: required_count,
distinct_approver_count, threshold_met, and approvers with approved_at
plus assurance and evidence_ref when recorded. Tests prove reconstruction
from the use row alone, and that the claim still discloses no approver
identities -- they are evidence for audit-core, not consumer-facing, and
the claim keeps disclosing the least it can.
Writing the tests showed distinctness is already a storage invariant:
entries is UNIQUE on (approval_id, subject_id), so a repeat approver is
refused at insert and a separate entry_count could never differ from the
distinct count. Dropped that field rather than ship a number that cannot
vary, and the test now asserts the refusal instead.
88 tests pass (4 new).
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
fix-consistency C-32 registered the outcome block in the request doc as
hub decision b606e8ce and wrote the id back. Resolved it in the hub with
decided_by gate-house, since gate-house decided it on 2026-09-06 and a
record left open misrepresents live state in estate-wide open-decision
queries. The rationale records that this hub row was created from
approval-engine's repo and that gate-house's decisions.md remains the
source of truth for GH-prefixed decisions.
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
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
Gate House confirmed all three requested dispositions as GH-DEC-2026-005
(GH-IN-0002, closed); flex-auth accepted as FLEX-DEC-2026-006. The
approval-claim is the step-1 artifact, ActionAuthorization is not
required and MUST NOT be served from the claim endpoint, and a PEP
validates across the claim and the step-2 DecisionEnvelope. Gate House
recorded the split as doctrine rather than convenience -- a PIP must not
republish the PDP's decision -- and struck the provenance.authority ==
state-hub requirement explicitly. This engine's claim schema is
unchanged.
Correct the deferred option D trigger list. The G3 trigger was written
conditional on G3 being settled by composition; flex-auth reports
FLEX-WP-0019 closed it by adding a lifetime field to DecisionEnvelope on
2026-09-02, so a decision now states its own end without borrowing
ActionAuthorizationValidity. That was the one structural thing the bundle
did that the split does not, so the trigger is not merely spent -- it
resolved against ratification. Struck with reasons; a future revisit
needs a fresh argument. The trigger came from a stale row in a dated
2026-08-29 review record that flex-auth does not rewrite.
Also record the root cause of the bad authority constant: it came from a
flex-auth fixture, not prose. A contract whose examples contradict its
prose will be implemented as its examples.
Close APPROVAL-IN-0002. 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
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
secrets-engine reports its PIP join is implemented and blocked on
deployment rather than contract. Reviewing its
validate_action_authorization against what this engine actually serves
shows that is not the whole story: it expects a state-hub-authority
ActionAuthorization (id, status, superseded_by, request,
approvals.entries, policy pin) while GET /v1/approvals/{id}/claim serves
the governed approval-claim (approval_id, state/valid_now, binding,
freshness, reason_code, issuer approval-engine).
Both envelopes declare schema_version 0.1, so the version check passes
and the mismatch surfaces as a field or authority error that reads like
an approval-engine outage.
Document the field-by-field divergence and why the omissions are
deliberate: a claim is a fact about an approval object, not a decision,
so approver identities and policy pins are not republished. Reconciling
the envelopes is a GH-DEC-2026-003 cross-repo change, so the governed
claim schema is left unchanged here.
No code change; 84 tests still 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
Close remaining in-repo APPROVAL-WP-0002 gaps: drive GH-DEC-2026-003 against
the real HTTP surface, fail closed on JWT/human-consume/static-token paths,
treat audit 200 duplicates as drained, and ask KeyCape for the production
audience and client grants.
Assistant: grok
Assistant-Session: 01a06253-e557-7971-93d9-4f4c2cfbf455
Contracts first (T02–T04): approval claim schema with issuer, freshness,
and binding digest; local transactional outbox wire; load-bearing cadence
as heartbeat or reconciliation (layer.yaml declared).
Then the object (T06–T08): SQLite closed state machine, CAS supersession,
distinct-approver fail-closed, revocation without holder cooperation,
outbox insert in the same transaction. Tests fail the mutation when
emission fails, and revoke while the drain sink is down.
Introspection GET /v1/approvals/{id}/claim is a PIP fact, not a decision.
No public consume (T05 waits on GH-WP-0002-T06). Canon T-06 coverage for
wrong binding, expiry, revoke, and supersede.
FLEX-WP-0017 T03 is unblocked on this object; T05 remains blocked only on
consumption ordering.
Assistant: grok
Assistant-Session: 01a04ceb-2057-7e20-b0f9-c282964d5dd9
