76 lines
3.3 KiB
Markdown
76 lines
3.3 KiB
Markdown
# Decision records
|
|
|
|
## TEN-DEC-2026-001 — Declare Engine / PIP; contest approval lifecycle here
|
|
|
|
```yaml
|
|
id: TEN-DEC-2026-001
|
|
kind: decision
|
|
title: "Declare Engine / PIP; contest approval lifecycle here"
|
|
status: resolved
|
|
disposition: approved
|
|
origin: cross-repo
|
|
origin_ref: TEN-IN-0003
|
|
standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
|
|
companion: net-kingdom/SECURITY-COMPANION.md
|
|
owner: tenant-engine
|
|
affects:
|
|
- tenant-engine
|
|
- gate-house
|
|
- net-kingdom
|
|
- access-engine
|
|
- approval-engine
|
|
created: "2026-08-29"
|
|
updated: "2026-08-29"
|
|
decided_by: tenant-engine (reviewing side)
|
|
decided_at: "2026-08-29"
|
|
state_hub_decision_id: "34cfa01f-57c8-4576-b8df-6a1b81baaef5"
|
|
```
|
|
|
|
## Context
|
|
|
|
gate-house asked this repository, via `TEN-IN-0003`, to declare its layer in
|
|
`INTENT.md` in its own voice, or contest it. Proposed layer: Engine —
|
|
tenant-as-an-entity facts. The existing boundary contract was to hold
|
|
unchanged. One live question: the reserved guardrail/quota policy was
|
|
briefly considered as a home for organizational approval lifecycle before
|
|
`approval-engine` was seeded; if approvals belong nearer tenant governance,
|
|
now is the time to say.
|
|
|
|
The NetKingdom Security Layer Model was accepted at v0.7 on 2026-08-29. The
|
|
working companion is `net-kingdom/SECURITY-COMPANION.md` v0.2. Statute §4
|
|
already catalogues this repository as Engine / PIP. Statute §11 says a layer
|
|
stated *about* a repository is not a declaration; only this file, in this
|
|
repository's voice, conforms. The previous `INTENT.md` carried a gate-house
|
|
review note naming Engine above a line that admitted the body was unadapted.
|
|
|
|
## Decision
|
|
|
|
1. **Declare Engine, role PIP.** Same authoritative tenant state yields the
|
|
same result. This repository supplies tenant-as-an-entity facts as claims
|
|
a decision consumes. It does not render or cache an authorization
|
|
decision. `access-engine` (`flex-auth` until the governed rename) remains
|
|
the only PDP. The declaration lives in `INTENT.md` frontmatter
|
|
(`layer: Engine`, `role: PIP`) and in the body's own-voice note.
|
|
2. **Contest placing approval lifecycle here.** A guardrail is a safety
|
|
ceiling — a PIP fact. An approval is a durable object owned by
|
|
`approval-engine` (statute §4, §9.4) and consumed as a claim by
|
|
`access-engine`. Tenant governance will not mint, store, or evaluate
|
|
approvals. If a tenant mutation should require one, the write stays
|
|
PEP-shaped: this engine mutates only after `access-engine` has allowed
|
|
it, and that decision may rest on an `approval-engine` claim.
|
|
3. **Name the write path PEP-shaped without becoming a PDP.** Protected
|
|
side effects (create, grant, revoke, plan, lifecycle, grouping,
|
|
guardrail mutations) proceed only with a decision record or a recorded
|
|
fail-closed unreachable-engine stance. That stance is already the
|
|
shipped default; publishing it and persisting decision ids is
|
|
implementation, recorded as `TEN-WP-0011`, not a change of layer.
|
|
|
|
## Consequences
|
|
|
|
- `TEN-IN-0003` is closed, absorbed by this decision.
|
|
- Implementation gaps against v0.7 are not hidden by the declaration.
|
|
They are `TEN-WP-0011`.
|
|
- A boundary-contract amendment in `net-kingdom` is requested from that
|
|
workplan: guardrails are no longer reserved, and "not a policy
|
|
enforcement point" must be restated so it cannot be read as denying the
|
|
PEP *shape* of our writes.
|