Two corrections from the repositories that implemented the decision, both
volunteered against their own interest.
approval-engine and flex-auth independently reported that the deferred
option's G3 revisit trigger was already spent when the decision was
written. Verified here against flex-auth/schemas/decision_envelope.schema.json:
FLEX-WP-0019 closed G3 on 2026-09-02 by adding the field, not by
composition. That resolves against ratification — carrying its own end was
the one structural thing the composed bundle did that the split does not,
so the strongest case for option D is answered, and the answer is no.
secrets-engine reported that the split reduces what the PEP verifies: the
distinct-approver threshold is now folded into valid_now and no longer
checked independently. Correct on layering and a real reduction; both are
true. Recorded with its compensating property — reconstructability at the
issuer under §9.6, which is detection rather than prevention.
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
GH-WP-0003-T03. maturity-engine holds the §13 gap register and the §13.1
stance-map inventory as queryable data and proposed the statute tables
become pointers. Two things are true at once: a statute should not carry
state, and a standard must be readable on its own.
The registers become pointers, and not before maturity-engine publishes a
committed, versioned export readable without a live query. Publication is
the migration's precondition, not its follow-up — pointing an auditor at
a live engine is not a register they can read, and would repeat in the
other direction the exact defect §13.1 was created to fix.
Until the export lands the tables stay and rows are transcribed, so
user-engine, tenant-engine, ops-warden and ops-mason are inventoried in
v0.8 either way rather than waiting on the condition.
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
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
correlation_id: 1fd8961e-6174-4479-8bd8-ca17ee5f9040
reason: GH-WP-0002-T03: record the revocation failure mode so it is not an implementation accident
source: repo-manager
Assistant: grok
Assistant-Session: 01a04d89-aaa5-7443-945e-b3055cd4b7e4
correlation_id: 7ac7bd1d-2de1-4158-997a-d7b4bb2fb0d5
reason: Ratify the three linked rulings from the 2026-08-28 security estate review
source: repo-manager
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
