coulomb/approval-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
An engine for modelling and managing decisions.
39 commits 1 branch 0 tags 530 KiB
Find a file
tegwick 119359c33d Reconcile the release record; guard the image pin with tests 
The publication at b51d174 pinned the manifest and appended a note, but left
three documents asserting the opposite. docs/image-scan-2026-09-06.md said "It
has not been pushed" in its Outcome block at the top while recording the
successful push at the bottom; its "Release status" section still said no
release digest existed and the manifest carried REPLACE_WITH_RELEASE_DIGEST;
and deploy/README.md still instructed an operator to replace a placeholder that
is now a real digest -- an instruction to undo the pin.

This is the derived-artifact staleness this repo argued for a rule about in
v0.8 §12 and then produced in its own release evidence, in the file another
repository would read to confirm what shipped. Superseded sections are now
marked in place with what replaced them rather than deleted, since they record
why the base changed and why the release was held. The scan doc carries a
status marker naming which parts state current state, including that a clean
scan is point-in-time and ages as advisories are published.

The workplan gains the publication entry it never got, and a re-check of T03's
full acceptance: a published image reads like a finished task, but the digest
was one of five requirements. Nothing is deployed -- the namespace is empty and
no secrets exist -- and production serve refuses to start without authenticated
audit delivery, so a rollout today would fail closed and prove nothing. T03
stays wait on T01's registrations and the audit credential.

Also corrects an earlier caution in the workplan that the digest was "a local
image id, not a release digest". That was wrong: with the containerd/OCI store
the build id is the manifest digest, and the registry resolves it.

tests/test_deploy_manifest.py holds the pin mechanically instead of by review:
both image references exist, are digest-pinned rather than tagged, are
identical, and no placeholder remains. The identity check matters because the
init container migrates the database the server then serves -- two different
digests there is a split-brain migration. Verified the guard fails on the drift
it targets, not only that it passes today. 116 tests pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PM5HnEAhokxdfcPqBNpT7D

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715850@bnt-lap001
Assistant-Session: eb557e93-7cb1-45d0-9e57-7d15b3edc60e
2026-09-07 09:04:34 +02:00
approval_engine Set the approval store tenant to exact tenant:platform 2026-09-06 22:33:50 +02:00
deploy Reconcile the release record; guard the image pin with tests 2026-09-07 09:04:34 +02:00
docs Reconcile the release record; guard the image pin with tests 2026-09-07 09:04:34 +02:00
examples Implement GH-DEC-2026-008: declared PDP-path intent, enforced at issue 2026-09-06 14:51:23 +02:00
history Align to security layer model v0.7 and open the engine spine 2026-08-29 11:58:28 +02:00
intakes Record GH-DEC-2026-005; strike the spent G3 revisit trigger 2026-09-06 01:36:03 +02:00
schemas Name the execute-time digest target; record the tenant collision 2026-09-06 20:35:59 +02:00
tests Reconcile the release record; guard the image pin with tests 2026-09-07 09:04:34 +02:00
workplans Reconcile the release record; guard the image pin with tests 2026-09-07 09:04:34 +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 Adopt Alpine as the sanctioned base; release candidate scans clean 2026-09-06 23:01:41 +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 Adopt Alpine as the sanctioned base; release candidate scans clean 2026-09-06 23:01:41 +02:00
pyproject.toml State pdp_digest explicitly; decline to publish a vocabulary mapping 2026-09-06 09:32:11 +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 chore(consistency): record decision id for GH-DEC-2026-005 2026-09-06 08:05:00 +02:00

README.md

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.