tenant-engine/decisions/decisions.md

Decision records

TEN-DEC-2026-001 — Declare Engine / PIP; contest approval lifecycle here

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.