An engine for modelling and managing decisions.
Find a file
tegwick 7fd841f773 Draft the gate-house decision request on the claim envelope
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
2026-09-06 01:23:58 +02:00
approval_engine Harden the PEP harness and KeyCape registration request 2026-09-02 15:46:06 +02:00
deploy Implement approval engine production readiness 2026-09-02 00:52:04 +02:00
docs Draft the gate-house decision request on the claim envelope 2026-09-06 01:23:58 +02:00
examples Implement the engine spine: claim, outbox, machine, API 2026-08-29 12:52:49 +02:00
history Align to security layer model v0.7 and open the engine spine 2026-08-29 11:58:28 +02:00
intakes Draft the gate-house decision request on the claim envelope 2026-09-06 01:23:58 +02:00
schemas Implement the engine spine: claim, outbox, machine, API 2026-08-29 12:52:49 +02:00
tests Harden the PEP harness and KeyCape registration request 2026-09-02 15:46:06 +02:00
workplans Record the claim vs ActionAuthorization envelope divergence 2026-09-06 01:09:23 +02:00
.custodian-brief.md chore(consistency): sync task status from DB [auto] 2026-09-06 01:09:55 +02:00
.gitignore Implement the engine spine: claim, outbox, machine, API 2026-08-29 12:52:49 +02:00
.repo-classification.yaml Add repo classification to close C-24/C-35 2026-08-29 14:43:52 +02:00
AGENTS.md Finish approval engine spine 2026-09-01 23:45:48 +02:00
cadence.yaml Finish approval engine spine 2026-09-01 23:45:48 +02:00
Containerfile Implement approval engine production readiness 2026-09-02 00:52:04 +02:00
INTENT.md Finish approval engine spine 2026-09-01 23:45:48 +02:00
layer.yaml Implement the engine spine: claim, outbox, machine, API 2026-08-29 12:52:49 +02:00
Makefile Implement approval engine production readiness 2026-09-02 00:52:04 +02:00
pyproject.toml Implement approval engine production readiness 2026-09-02 00:52:04 +02:00
README.md Harden the PEP harness and KeyCape registration request 2026-09-02 15:46:06 +02:00
SCOPE.md Harden the PEP harness and KeyCape registration request 2026-09-02 15:46:06 +02:00
WORK-RECORDS.md Implement approval engine production readiness 2026-09-02 00:52:04 +02:00

approval-engine

The approval as a durable, authenticated, consumable object — issued before an action, verified at the moment of use, and provably not replayable.

An Engine, role PIP, in the NetKingdom security layer model (statute v0.7, accepted; operative form net-kingdom/SECURITY-COMPANION.md). It answers one question, totally and decidably:

Is this approval valid right now — for this exact action, target, actor, and purpose — and has it already been used?

It does not decide whether the action is permitted. That is access-engine, which stays NetKingdom's only policy decision point. An approval is one input to that decision.

Deliberately small, boring, and strict: atomic supersession and single consumption are what make Canon test T-06 — Approval Replay passable. Flexibility here would be a defect. Graded, evidence-based progression belongs to maturity-engine; the two engines are deliberate opposites.

See INTENT.md and SCOPE.md. Declaration: layer.yaml. Claim: docs/approval-claim.md. Consume: docs/approval-consumption.md. Caller auth: docs/caller-authentication.md. PEP sequence: docs/pep-integration.md. Origin: flex-auth FLEX-DEC-2026-001, raised while assenting to the security layer model.

make test
approval-engine migrate --db approvals.sqlite
approval-engine verify --db approvals.sqlite
approval-engine serve --db approvals.sqlite \
  --jwt-issuer https://auth.netkingdom.local \
  --jwt-audience approval-engine \
  --jwks-url http://key-cape.sso.svc.cluster.local:8080/jwks

POST /v1/approvals/{id}/consume implements GH-DEC-2026-003: the PEP atomically spends the approval before the protected side effect. Same-digest retries are idempotent; a different digest conflicts.

Production operations, caller scopes, audit delivery, and PEP sequencing are documented in docs/storage-operations.md, docs/caller-authentication.md, docs/outbox-contract.md, and docs/pep-integration.md. The checked-in StatefulSet deliberately refuses production startup without a migrated persistent store, KeyCape JWT verification, and authenticated audit delivery.