A policy-as-code capable authorization registry/control-plane service.
Per gate-house GH-DEC-2026-001 and net-kingdom canon security-layer-model_v0.1. The rename to access-engine is NOT part of this change; it remains a separate governed migration. - Drop the "control plane" self-description: that is Staff-layer vocabulary, and flex-auth is an Engine — a deterministic API where the same authoritative input state yields the same result. - State the exclusive role: flex-auth is the only policy decision point in NetKingdom. No other repository, in any layer, renders or caches a decision. - Split authoring from evaluation. flex-auth owns evaluation exclusively plus the policy-as-code mechanism; gate-house owns the doctrine, invariants, authority ceilings, operating modes, and the authority context consumed as input claims; policy content stays with the protected system's owner. - Record the access lane/rule demarcation: ops-warden and ops-mason own lanes (how a worker reaches a host), flex-auth owns rules (whether they may). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9 |
||
|---|---|---|
| .claude/rules | ||
| .forgejo/workflows | ||
| .github/workflows | ||
| charts/flex-auth | ||
| cmd/flex-auth | ||
| deploy | ||
| docs | ||
| examples | ||
| internal | ||
| pkg/api | ||
| railiance | ||
| registry | ||
| schemas | ||
| tests | ||
| tools | ||
| values | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .golangci.yml | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| Containerfile | ||
| go.mod | ||
| go.sum | ||
| INTENT.md | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| SCOPE.md | ||
| tenancy.yaml | ||
| WORK-RECORDS.md | ||
flex-auth
Policy-as-code authorization registry and control plane for NetKingdom-aligned systems.
Start with INTENT.md for the project boundary and direction. Research notes and ADRs live in docs/ and docs/adr/.
The product boundary is captured in SCOPE.md, and the current Product Requirements Document is docs/ProductRequirementsDocument.md.
The 2026-05-15 pre-implementation assessment that shapes the current sequencing is in docs/pre-implementation-assessment.md.
The CARING reference-implementation approach is captured in docs/caring-architecture-blueprint.md.
Workplans live in workplans/, with sequencing captured in docs/workplan-planning-map.md.