zone-engine/INTENT.md

INTENT

Why zone-engine exists and where it is going. What is true today is SCOPE.md. Checkable gates and the retirement condition are GOAL.md. This file is the argument, not the checklist.

---

1. The sentence this repo exists to make sayable

"This control is enforced there, advisory here, and relaxed in this band until Friday — and all three of those are written down, reviewable, and expire on their own."

NetKingdom cannot say that today. It can say how exposed a workload is (environment posture), how ready it is (M0–M3), and what state the organization is in (organization_posture). Every one of those describes. None of them decides. So every enforcement control in the estate has been a boolean over a whole repo.

2. Where that bit

ops-warden built a pre-sign authorization gate, flex-auth enforced its side, and the gate verified clean. Then it was deliberately not switched on.

policy.enabled is one boolean over the entire repo. With fail_closed: true it makes flex-auth a hard dependency of every warden sign — including the SSH certificates the ops-bridge tunnels depend on, one of which carries the policy call itself. Turning it on would have been correct for a settled production lane and wrong for an estate in the middle of decommissioning one host and moving a service off it.

That is not a story about a flag. Security that stops the work stops being security and becomes an outage with good intentions — and the reason it would 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

A classification that changes nothing is a label. A zone earns its keep only if it decides something, so the model must carry:

• Membership — what puts a lane, actor or workload in a zone, derived from posture already declared rather than a fourth hand-maintained list.
• Stance per control — enforced, advisory, or exempt.
• Failure mode — what happens when the control cannot run. This is where the bite is; fail_closed is what turns a dead tunnel into an outage.
• Exceptions that expire without anyone remembering them.

The last is the reason this is a repo rather than a document. A standing classification needs no engine — canon plus a declaration file covers it, which 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

flex-auth is the policy decision point. It stays the only one.

zone-engine is authority over zone identity and membership. The effect of a zone on a decision flex-auth renders belongs in a flex-auth policy package, because flex-auth's decision envelope stamps matched_policy_version and policy_package — and registry content appears nowhere in that provenance. Put stance in the registry and two decisions with the same policy version and the same request can differ, with nothing in the audit trail explaining why.

That boundary was drawn by flex-auth on review, against a first draft of ours that got it wrong in an instructive way: the original invariant forbade sitting synchronously in a decision path, which is a latency guarantee wearing an authority guarantee's clothes. Compiled data that determines an outcome is still 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

Someone who has never read this repo should be able to:

• open a service's tenancy.yaml, read its zones: key, and know which controls bite it;
• ask "why was this relaxed?" and get a justification, an author and an expiry, not a shrug;
• watch a relaxation lapse without a human remembering it;
• and find the rule published in NetKingdom canon rather than in this repo's prose.

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

Stated up front, because a repo created on a recommendation should say what would falsify it:

• The exception lifecycle turns out not to need a runtime. If reviewed declarations in git, with expiry evaluated at decision time, are sufficient, then the honest outcome is a canon standard and no engine — and this repo should be archived rather than kept for the sake of existing. GOAL.md gate 5 and ZONE-WP-0001-T04 both hold that door open deliberately.
• The zones do not partition the real estate. If the model needs a residue of special cases to cover today's 27 routing lanes and actor inventory, it is describing an aspiration, not a structure.
• Nobody but the author declares one. Two repos declaring and a third reading is the minimum evidence of a model rather than a preference.
• It becomes a second decision point. The failure would not announce itself; it would arrive as a small convenience — a stance compiled into membership "just for now".

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 and are repo-manager's, and the fact that reef-railiance caps availability 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

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 the zones: key that canon has already reserved. Two consumers before it is called adopted, the first being ops-warden retiring policy.enabled.

A runtime only if ZONE-WP-0001-T04 proves the exception lifecycle needs one — and the cheaper answer is a legitimate result, not a disappointment.