approval-engine/README.md
tegwick c3f1dfbc07 Finish approval engine spine
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a05e2e-805b-7042-a750-71f473bceea2
2026-09-01 23:45:48 +02:00

35 lines
1.5 KiB
Markdown

# 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](INTENT.md) and [SCOPE.md](SCOPE.md). Declaration: [layer.yaml](layer.yaml).
Claim: [docs/approval-claim.md](docs/approval-claim.md).
Consume: [docs/approval-consumption.md](docs/approval-consumption.md).
Origin: `flex-auth` `FLEX-DEC-2026-001`, raised while assenting to the security
layer model.
```bash
make test
python3 -m approval_engine.cli serve --db approvals.sqlite
```
`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.