coulomb/zone-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Headless multi-application, multi-tenant security zone mangement engine.
11 commits 1 branch 0 tags 565 KiB
Find a file
tegwick ce716c4ae3 Correct the subject: policy is about the workload, and a zone is an admission floor 
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>
2026-08-19 23:36:31 +02:00
docs Correct the subject: policy is about the workload, and a zone is an admission floor 2026-08-19 23:36:31 +02:00
workplans ZONE-WP-0001-T03: maturity-derived risk defaults, and what they can attach to 2026-08-19 23:23:49 +02:00
.custodian-brief.md chore(consistency): sync task status from DB [auto] 2026-08-19 21:19:35 +02:00
.gitignore chore: track scaffold gitignore and custodian brief 2026-08-19 21:20:12 +02:00
.repo-classification.yaml Seed zone-engine — authority for security zones and exception lifecycle 2026-08-19 21:18:44 +02:00
AGENTS.md Seed zone-engine — authority for security zones and exception lifecycle 2026-08-19 21:18:44 +02:00
GOAL.md Refine SCOPE, add INTENT, fix the GOAL invariant flex-auth rejected 2026-08-19 22:20:13 +02:00
INTENT.md Correct the subject: policy is about the workload, and a zone is an admission floor 2026-08-19 23:36:31 +02:00
README.md Seed zone-engine — authority for security zones and exception lifecycle 2026-08-19 21:18:44 +02:00
SCOPE.md Correct the subject: policy is about the workload, and a zone is an admission floor 2026-08-19 23:36:31 +02:00
WORK-RECORDS.md ZONE-WP-0001-T03: maturity-derived risk defaults, and what they can attach to 2026-08-19 23:23:49 +02:00

README.md

zone-engine

Headless authority for security zones — named bands of the estate with different enforcement rigidity, and the lifecycle of time-boxed exceptions to them.

A zone answers a question no existing axis answers: is this control enforced here, and what happens when it fails? NetKingdom can already say how exposed a workload is (environment posture), how ready it is (workload maturity M0–M3), and what state the organization is in (organization_posture). All three describe. None decides.

zone-engine is not a policy decision point. flex-auth remains the only PDP; zone membership reaches it by compilation into the registry it already consumes, never by a synchronous lookup in the decision path.

Orient: GOAL.md → SCOPE.md → workplans/.