diff --git a/INTENT.md b/INTENT.md index 83b29a1..307d48c 100644 --- a/INTENT.md +++ b/INTENT.md @@ -35,30 +35,7 @@ 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 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 +## 3. 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: @@ -76,7 +53,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. -## 5. The line this repo must not cross +## 4. The line this repo must not cross `flex-auth` is the policy decision point. It stays the only one. @@ -96,7 +73,7 @@ deciding; it just decided earlier. **Held to, in one line: membership is ours, stance is theirs, and the decision point is neither.** -## 6. What success looks like from outside +## 5. What success looks like from outside Someone who has never read this repo should be able to: @@ -111,7 +88,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. -## 7. What would make this repo wrong +## 6. What would make this repo wrong Stated up front, because a repo created on a recommendation should say what would falsify it: @@ -130,7 +107,7 @@ would falsify it: it would arrive as a small convenience — a stance compiled into membership "just for now". -## 8. What this repo deliberately will not become +## 7. 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* @@ -139,7 +116,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. -## 9. Direction +## 8. 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 3df20c2..e13b7c7 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -31,12 +31,9 @@ and this repo is what that ADR defers to. ## In scope -- **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. +- **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. - **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 684932d..8892f2d 100644 --- a/docs/estate-partition-2026-08-19.md +++ b/docs/estate-partition-2026-08-19.md @@ -105,16 +105,7 @@ Two further gaps, less severe but structural: ### Is a zone a property of the actor, the lane, the workload, or the moment? -> **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 — +**The lane**, on the evidence. 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. @@ -160,66 +151,3 @@ 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. diff --git a/workplans/ZONE-WP-0001-security-zone-model.md b/workplans/ZONE-WP-0001-security-zone-model.md index 05f3341..fa83561 100644 --- a/workplans/ZONE-WP-0001-security-zone-model.md +++ b/workplans/ZONE-WP-0001-security-zone-model.md @@ -222,15 +222,6 @@ Answer explicitly: **Done 2026-08-19.** Full result: `docs/estate-partition-2026-08-19.md`. -> **Corrected the same day by operator direction, recorded in §7 of that -> document.** Policy is about the **workload**, not the lane; the software repo -> only *suggests*; the workload and its responsible party declare the scrutiny; -> and a zone **requires** a standard for admission — a workload qualifies to run -> in a zone rather than being labelled with one. This is `tenancy-posture` -> Decision 8.2's tier-minimum mechanism, which Decision 5.6 had already said -> stance would behave as. The four bands below survive as membership *inputs*, -> not as zones. - Four bands, each of the 27 lanes in exactly one — **Decided** (1, the only lane ops-warden decides), **Fronted** (10, owner has a front door), **Covered** (12, ops-warden proxies what it does not own), **Signposted** (4, routed, nothing @@ -321,23 +312,6 @@ field repeats the error net-kingdom rejected when it refused stance as a tenancy axis. Model them as two fields: grade (derived, defaultable) and acceptance (asserted, owned, expiring). -**Resolved by the T02 correction.** Grade and acceptance are the two sides of a -Decision 8.2 join: the zone asserts a floor, the workload asserts its posture, -and the join is mechanical. Not two fields to invent — one join to implement. - -**And the join is now the critical path.** ops-warden's catalog contains no -workloads, so there is no subject to attach an admission standard to. `M0`-`M3` -already grades workloads, which is the side that exists; what is missing is -anything declaring which workload consumes which lane. T03 cannot produce a -usable stance model until that is answered, and the honest answer may be that it -belongs to whatever declares workloads — not to this repo. - -**Build stage is a positional fact, not a concession.** The organization is in -`build`; the default stance is permissive and zones tighten by *admission*, -rather than by raising a global floor. That is what makes this model compatible -with deep refactoring instead of hostile to it, and it is the same reasoning -that produced `ADR-0006`. - **Amended by flex-auth 2026-08-19 — split membership from stance.** ops-warden's option (c) ("zones as policy-package data") was rejected wholesale because the model must govern two controls flex-auth does not evaluate. flex-auth agrees with