Headless multi-application, multi-tenant security zone mangement engine.
Operator direction: an ungraded lane inherits the default its maturity context implies — accepted in experimental context, high or critical in production. M0-M3 is the right ladder and already carries rank, phase, max_dataclass and promotion gates; what it lacks is a join to lanes, which is T02's gap. .repo-classification.yaml category cannot carry it: railiance-platform, which runs production OpenBao and owns three of RISK-F-0003's five exposed lanes, is category tooling, while net-kingdom, a canon docs repo, is product. It orders work mode, not blast radius. Also records that maturity must come from the lane's owner, not the repo holding the catalog, and that 'accepted' is an acceptance rather than a grade — it needs an owner and an expiry, so it is a second field, not a rung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| docs | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| GOAL.md | ||
| INTENT.md | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.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/.