A policy-as-code capable authorization registry/control-plane service.
gate-house circulated security-layer-model v0.8 for assent. Assent given with four findings; F1 is fail-open and blocking for calling the section 6.4 PEP obligations complete, though not for anyone's adoption — the condition already exists under v0.7 and is not created by this version. F1. "A decision from access-engine" is not a checkable predicate. 6.4 obligation 1 requires a PEP to hold one; obligation 2 supplies a test it is emphatic is mechanical and not a judgement call. That test establishes which request a decision is for and nothing about who issued it, because every input to every digest a PEP can check is either sent by the caller or published. A responder knowing the package id and version reproduces all three exactly. What makes it sharp is internal: 9.4 requires the approval object to carry authenticated entries, and 6.4 obligation 5 then requires each artifact be validated against its owning layer, naming the approval-claim and DecisionEnvelope pair as the live instance. So the obligation is unsatisfiable for half the pair it was written about — a PEP can validate the approval's authenticity and cannot validate the decision's. The asymmetry is argued nowhere. Section 16 already carries this observation one layer up, about the standard's own publication path having no digest or freeze discipline. Applied to the artifact the standard regulates, it is F1. The gap was visible from inside and got recorded against the wrong artifact. F2 answers the absent-vs-unknown question gate-house flagged as ours. Runtime behaviour must be identical — absent fails closed too, and for a stronger reason, since it is the branch reached by discovering your model of your own scope axis was wrong. But omitting the distinction makes totality unfalsifiable: a map with an unknown catch-all satisfies 6.4 obligation 3 vacuously, and its drift test passes by exercising the catch-all rather than the axis. Same defect we published as FLEX-DEC-2026-008 — coverage counted rather than executed, in a stance map instead of a fixture suite. F3. "The published map MUST equal the shipped behaviour, and that equality SHOULD be asserted by a test", in a paragraph arguing drift is worse than no publication. The strongest obligation in 6.4 has the weakest verification, and 13.1 shows four of five rows already test it. F4. 13.1 marks ops-warden's unknown cell non-conformant and states ops-mason's map as simply not published, which is a plainer violation of the same obligation, unmarked in the same table. Also answered their direct question: no, they did not over-read our divergence report. Added that the ruling costs us nothing, since we are not PEP-shaped, so our concurrence is weak evidence and ops-warden's assent is worth more here. FLEX-WP-0023-T05 and FLEX-WP-0024-T04 close. Notes T01-T03 landed from Glas meanwhile with real receipts including an actually-expired token, and that enforce authenticates the caller while leaving F1 untouched — as their own note says. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd Assistant: claude-code Assistant-Model: opus Assistant-Process: 715613@bnt-lap001 Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80 |
||
|---|---|---|
| .claude/rules | ||
| .forgejo/workflows | ||
| .github/workflows | ||
| .repo-manager | ||
| charts/flex-auth | ||
| cmd/flex-auth | ||
| decisions | ||
| deploy | ||
| docs | ||
| examples | ||
| history | ||
| intakes | ||
| 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.