2026-08-28 20:27:28 +00:00
|
|
|
# approval-engine
|
|
|
|
|
|
2026-08-28 22:33:50 +02:00
|
|
|
**The approval as a durable, authenticated, consumable object — issued before an
|
|
|
|
|
action, verified at the moment of use, and provably not replayable.**
|
|
|
|
|
|
|
|
|
|
An Engine in the NetKingdom security layer model. 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). Origin: `flex-auth` `FLEX-DEC-2026-001`, raised while
|
|
|
|
|
assenting to the security layer model.
|