coulomb/zone-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Correct the subject: policy is about the workload, and a zone is an admission floor

Browse source 
Operator direction. The T02 analysis concluded "a zone is a property of the
lane", which mistook the corpus for the subject — ops-warden's catalog is a
credential surface with no workloads in it, so lane properties were the only
thing available to partition. Partitioning what is available is not the same as
finding what policy applies to.

Three roles: the repo providing the software SUGGESTS a posture for running it;
the workload and its responsible party DECLARE the scrutiny applied, and are the
policy subject; the zone REQUIRES a standard for admission. A workload is not
labelled with a zone, it qualifies to run in one.

This is canon's existing mechanism, not a new one. Decision 8.2 already splits
authority this way and joins tier minima by machine, precisely so a checkable
constraint does not depend on someone remembering a signature; Decision 5.6
already ruled stance behaves as a tier minimum under it. It also dissolves the
grade-versus-acceptance question raised for T03 — they are the two sides of that
join.

Consequence: the four bands survive as membership inputs, demoted from
conclusions, and the missing lane-to-workload join is not a tidy-up. It is the
model. M0-M3 already grades workloads, which is the side of the join that exists.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-19 23:36:31 +02:00
parent 158efab24a
commit ce716c4ae3
3 changed files with 108 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

35
INTENT.md
View file

@ -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