tegwick
7e756773de
Gate House ruled binding.pdp_digest is the binding correspondence on the GH-DEC-2026-003 path and is required there, having rejected a vocabulary mapping for the reasons we gave. It asked this engine to record the PDP digest at issue for approvals intended for that path, and to have the claim state which approvals those are rather than leaving it to the requester's memory. Schema v3 adds approvals.pdp_path. create() refuses pdp_path true without a pdp_digest, so an approval that would be unusable on the path fails at issue rather than at the protected side effect. The claim exposes binding.pdp_path, which makes it a guarantee rather than a hint: pdp_path true implies pdp_digest is non-null. Intent is declared and never inferred. A pdp_digest that happens to be present is not a declaration anybody made, so a recorded digest alone leaves pdp_path false, legacy rows migrate to false rather than being back-filled from their digests, and a successor inherits its predecessor's declaration. Approvals issued before the ruling stay usable by consumers in this engine's own vocabulary and are simply not usable on the PDP path -- the ruling's intended cost, stated as such. Schema, both published examples, a v2-to-v3 migration test asserting survivors keep their digest while declaring no path intent, and tests for refusal at issue, claim exposure, non-inference, and successor inheritance. 102 tests pass (8 new). 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 |
||
|---|---|---|
| approval_engine | ||
| deploy | ||
| docs | ||
| examples | ||
| history | ||
| intakes | ||
| schemas | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| cadence.yaml | ||
| Containerfile | ||
| 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.
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.