diff --git a/INTENT.md b/INTENT.md index 307d48c..83b29a1 100644 --- a/INTENT.md +++ b/INTENT.md @@ -35,7 +35,30 @@ security and becomes an outage with good intentions** — and the reason it woul have was structural: there was nowhere to say *where* it applies. The decision is ops-warden's `ADR-0006`; this repo is what it defers to. -## 3. What a zone has to be, to be worth having +## 3. What policy is about, and who decides + +**Security policy is always about the actual workload.** Not the repository, not +the credential, not the lane — the running thing, and whoever answers for it. + +That splits authority three ways, and the split is the model: + +| Role | Who | Authority | +| --- | --- | --- | +| **Suggests** | The repo providing the software | Recommends a posture for running its software. It does not know where it will run, so it cannot determine | +| **Declares** | The workload and its responsible party | Sets the scrutiny actually applied. **The policy subject** | +| **Requires** | The zone | The standard a workload must meet to be admitted. A floor, not a label | + +A workload is not *labelled* with a zone. It **qualifies** to run in one. + +This is not a new prescription mechanism. `tenancy-posture_v0.1` Decision 8.2 +already splits authority this way — the consuming repo owns its workload +requirements, a tier minimum is owned separately, and the two are **joined by +machine**, because *"a machine-checkable constraint must not depend on somebody +remembering to collect a signature."* Decision 5.6 then ruled that stance +*"behaves like a tier minimum under Decision 8.2."* The zone model's job is to +**be** that tier minimum, not to invent a second way of requiring things. + +## 4. What a zone has to be, to be worth having A classification that changes nothing is a label. A zone earns its keep only if it decides something, so the model must carry: @@ -53,7 +76,7 @@ is exactly how tenancy posture works. **A relaxation with an expiry is state**, and state wants an owner, an audit trail, and something other than good intentions enforcing the deadline. -## 4. The line this repo must not cross +## 5. The line this repo must not cross `flex-auth` is the policy decision point. It stays the only one. @@ -73,7 +96,7 @@ deciding; it just decided earlier. **Held to, in one line: membership is ours, stance is theirs, and the decision point is neither.** -## 5. What success looks like from outside +## 6. What success looks like from outside Someone who has never read this repo should be able to: @@ -88,7 +111,7 @@ Someone who has never read this repo should be able to: If a reader has to come here to understand their own posture, the model has failed at being a standard and has succeeded only at being a service. -## 6. What would make this repo wrong +## 7. What would make this repo wrong Stated up front, because a repo created on a recommendation should say what would falsify it: @@ -107,7 +130,7 @@ would falsify it: it would arrive as a small convenience — a stance compiled into membership "just for now". -## 7. What this repo deliberately will not become +## 8. What this repo deliberately will not become Not a PDP. Not network segmentation — "zone" is overloaded and the routing sense is someone else's word. Not a placement model: reefs answer *where a thing runs* @@ -116,7 +139,7 @@ for everything bound to it is a canon composition problem (`NK-WP-0027`), not ours. Not an owner of anyone's controls — the controls stay with the repos that enforce them; this model only says where they bite. -## 8. Direction +## 9. Direction Model first, from the real estate. Canon standard drafted here and published by `net-kingdom`, in the family of `tenancy-posture_v0.1`. Membership declared in diff --git a/SCOPE.md b/SCOPE.md index e13b7c7..3df20c2 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -31,9 +31,12 @@ and this repo is what that ADR defers to. ## In scope -- **Zone identity and membership.** What zones exist, and what puts a lane, - actor or workload in one — derived from posture already declared rather than - a fourth hand-maintained list. +- **Zone identity and admission standards.** What zones exist, and the standard + a **workload** must meet to be admitted to one. Security policy is about the + running workload and whoever answers for it — the repo providing the software + only *suggests*. A zone is a floor a workload qualifies against, not a label + applied to it, and it is the `tenancy-posture` Decision 8.2 tier-minimum + mechanism rather than a new one. - **Time-boxed exception lifecycle.** A relaxation with an expiry enforced by something rather than intended, plus the record of who widened what, when, and until when. **This is the task that decides whether this repo needs a diff --git a/docs/estate-partition-2026-08-19.md b/docs/estate-partition-2026-08-19.md index 8892f2d..684932d 100644 --- a/docs/estate-partition-2026-08-19.md +++ b/docs/estate-partition-2026-08-19.md @@ -105,7 +105,16 @@ Two further gaps, less severe but structural: ### Is a zone a property of the actor, the lane, the workload, or the moment? -**The lane**, on the evidence. Every field that discriminates — +> **Corrected 2026-08-19 by operator direction, after this analysis was +> written.** The answer below ("the lane") mistook the corpus for the subject. +> **Security policy is always about the actual workload.** ops-warden's catalog +> is a credential surface, not a workload inventory, so lane properties were the +> only thing available to partition — and partitioning what is available is not +> the same as finding the policy subject. The bands in §2 stand as an accurate +> description of ops-warden's credential surface and remain useful membership +> *inputs*; they are not zones. See §7. + +**The lane**, on the evidence available in this corpus. Every field that discriminates — `delegation.mode`, `exec_capable`, `risk` — is a lane property. The actor inventory holds 4 actors mapping to a single lane and cannot carry a partition. No lane references a workload. @@ -151,3 +160,66 @@ and it is canon's, tracked as `NK-WP-0027`. graded** (`RISK-F-0003`). `delegation.mode` is usable today and is a better predictor. - Membership must be computed from the loaded model, not read from raw YAML. + + +--- + +## 7. Correction — the subject is the workload, and a zone is an admission standard + +Operator direction, 2026-08-19, after §1–§6 were written: + +> *Security policy is always about the actual workload. The repository providing +> the software may suggest security policy for running workloads in different +> situations, but the workload — and whoever is responsible for it — defines the +> level of scrutiny. Some zones may well define standards that have to be met in +> order to run as a workload in that zone.* + +This reverses the direction the analysis above assumed. It had zones as a +**classification derived from** properties. They are **bands with admission +standards**: a workload does not get labelled with a zone, it *qualifies* to run +in one. + +### Three roles, not one + +| Role | Who | Authority | +| --- | --- | --- | +| **Suggests** | The repository providing the software | Recommends a posture for running its software in given situations. A recommendation, never a determination — it does not know where its software will run | +| **Declares** | The workload and its responsible party | Sets the level of scrutiny actually applied. **This is the policy subject.** | +| **Requires** | The zone | Defines the standard a workload must meet to be admitted. A floor, not a label | + +### This is canon's existing mechanism, not a new one + +`tenancy-posture_v0.1` **Decision 8.2 — split authority, machine-reconciled** +already partitions authority this way: the package repo owns substrate numbers +and enforcement, *"the consuming repo owns its workload requirements"*, and a +tier minimum is owned separately and **joined by machine** at definition and +whenever either side changes — because *"a machine-checkable constraint must not +depend on somebody remembering to collect a signature."* + +And Decision 5.6, ruling on this very standard, already said stance *"behaves +like a tier minimum under Decision 8.2 — asserted elsewhere, joined by machine."* + +So the zone model does not need a new prescription mechanism. It needs to **be** +a tier minimum: the zone asserts a floor, the workload asserts its posture, and +the join is mechanical. That also resolves the grade-versus-acceptance split +raised for T03 — they are simply the two sides of the join. + +### What this does to the bands in §2 + +They survive as *inputs*, demoted from conclusions. `Decided` / `Fronted` / +`Covered` / `Signposted` accurately describe ops-warden's credential surface and +still predict where danger concentrates. What they cannot do is name the entity +policy applies to, because ops-warden's catalog contains no workloads. + +The missing join found in §4 is therefore not a tidy-up. **It is the model.** +Until something declares which workload consumes which lane, there is no subject +to attach a standard to — and `M0`–`M3` already grades workloads, which is the +side of the join that exists. + +### Build stage + +The organization is in `build`. The default stance is therefore permissive, and +that is a positional fact rather than a concession: `ADR-0006` deferred a global +gate for exactly this reason. Zones tighten by **admission to a zone**, not by +raising a global floor — which is what makes the model compatible with deep +refactoring instead of hostile to it.