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
