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
fix-consistency assigned state hub intake 01a073e3 to APPROVAL-IN-0002
and regenerated the work-record index after the decision request landed.
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
Updated by fix-consistency on 2026-09-06:
- update .custodian-brief.md for approval-engine
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
Tooling / infotech PIP for the approval object. Validated against the
Repo Classification Standard; rmgr conform is clean.
Assistant: grok
Assistant-Session: 01a04ceb-2057-7e20-b0f9-c282964d5dd9
Updated by fix-consistency on 2026-08-29:
- update .custodian-brief.md for approval-engine
Assistant: grok
Assistant-Session: 01a04ceb-2057-7e20-b0f9-c282964d5dd9
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
Updated by fix-consistency on 2026-08-29:
- update .custodian-brief.md for approval-engine
Assistant: grok
Assistant-Session: 01a04ceb-2057-7e20-b0f9-c282964d5dd9
Produced by statehub fix-consistency (C-33). APPROVAL-WP-0001 is listed;
UUIDs land on the registrar pass.
Assistant: grok
Assistant-Session: 01a04ceb-2057-7e20-b0f9-c282964d5dd9
Updated by fix-consistency on 2026-08-29:
- update .custodian-brief.md for approval-engine
Assistant: grok
Assistant-Session: 01a04ceb-2057-7e20-b0f9-c282964d5dd9
The statute is accepted at v0.7; the operative form is
net-kingdom/SECURITY-COMPANION.md v0.2. INTENT now declares Engine / PIP
in its own voice, carries the §9.6 threat decomposition, the load-bearing
heartbeat obligation, issuer and freshness on the claim, consumption as a
mutation, and the custody question closed rather than held open.
SCOPE.md is the first-cut boundary (nothing shipped). layer.yaml is the
machine-readable declaration. The review under history/ scores intent vs
scope vs the empty implementation. APPROVAL-WP-0001 sequences contracts
before code and keeps consumption unimplemented until GH-WP-0002-T06.
Registered with State Hub as infotech / approval-engine.
Assistant: grok
Assistant-Session: 01a04ceb-2057-7e20-b0f9-c282964d5dd9
From the v0.5 review round.
- The outbox is local, in this engine's own transactional store, with no
synchronous audit-core dependency inside the state-change transaction. Raised
by audit-core: "or equivalent" would otherwise let an implementer satisfy
atomicity by emitting synchronously, turning an audit outage into an
inability to revoke.
- The claim must carry the approval identifier and a digest over the same
canonical binding access-engine already computes, so "approved" and "approved
for this exact request" are distinguishable at decision time. Raised by
flex-auth, needed for FLEX-WP-0017 T05.
- Consumption ordering is recorded as UNRESOLVED rather than guessed. The
decision precedes the action and the action precedes consumption, so an
allow never consumed, a double consumption by racing callers, and consumption
after a failed action are gaps neither engine closes alone. Nothing may be
implemented by assuming that contract.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
Condition of audit-core's assent to the approval evidence half
(AUDIT-IN-0001), now in the standard at §9.4.
Every issuance, use, supersession, and revocation is emitted in the same
transaction as the state change. Emit-after-commit is a defect, not an
optimization.
The reasoning is carried here rather than by reference because it constrains
implementation from the first commit: an append-only archive proves records
were not altered or truncated after arrival, but cannot prove one was never
sent (§9.6). A suppressed event leaves the chain intact and verification
reports intact. For approvals the most valuable event to suppress is a
revocation, so completeness is this engine's obligation and nothing downstream
can retrofit it.
Also records that audit-core's guarantee is bounded — not WORM, not object
lock, tamper evidence conditional on live preconditions — and that whether
approvals warrant stronger custody is an open gap this engine must not assume
closed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
approval-engine owns the approval object: durable, authenticated entries,
atomic supersession, single consumption, revocation without holder
cooperation. It is an Engine; access-engine remains the only decision point
and consumes approvals as input claims.
Origin: the unowned half of the approval contract, raised by flex-auth in
FLEX-DEC-2026-001 while assenting to the security layer model. Not gate-house
(Staff holds no runtime state), not access-engine (an evaluator that owns what
it evaluates is self-dealing), not audit-core (append-only, wrong property).
The seed README described this as "modelling and managing decisions" —
withdrawn. Under the standard, "decision" is access-engine's word.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
