Updated by fix-consistency on 2026-08-29: - update .custodian-brief.md for approval-engine Assistant: grok Assistant-Session: 01a04ceb-2057-7e20-b0f9-c282964d5dd9 |
||
|---|---|---|
| approval_engine | ||
| docs | ||
| examples | ||
| history | ||
| schemas | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| AGENTS.md | ||
| cadence.yaml | ||
| INTENT.md | ||
| layer.yaml | ||
| Makefile | ||
| pyproject.toml | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.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.
Origin: flex-auth FLEX-DEC-2026-001, raised while assenting to the security
layer model.
make test
python3 -m approval_engine.cli serve --db approvals.sqlite
There is no public consume. That waits on GH-WP-0002-T06.