A policy-as-code capable authorization registry/control-plane service.
tegwick
b30c858d46
FLEX-IN-0002 asked for review of v0.3; v0.4 supersedes it, so the assessment is against v0.4 plus the in-place section 11 amendment. Assent, with one rule contested: - Section 9.3 conflates two failure cases. Input degradation inside a reachable engine is flex-auth's fallback and is accepted. Engine unreachability is not: there is no evaluator in the path to express anything, which is why flex-auth has held that fail-open is not expressible by a PDP at all. As written 9.3 also collides with ops-warden ADR-0009 (accepted, superseding ADR-0006), which retires the global flag for a total per-zone map in the consumer PEP — the correct design, since the alternative makes flex-auth a hard dependency of the SSH certificate the tunnel carrying the policy call depends on. - Section 13 names access-engine as intended owner of two capabilities never reviewed here. Containment is plausible and recorded as proposed owner only. Authentication/assurance evidence is declined as stated: flex-auth consumes assurance claims and never re-defines them. - Three consistency defects: frontmatter status proposed vs section 14 "accepted"; "seven of fifteen"/"remaining eight" against sixteen estate-authored catalog rows and nine listed; "all three repositories" above a table of four. FLEX-IN-0002's two questions answered: the approval boundary unblocks T03 design, but T05 needs the approval claim bound to the same request digest NewDecisionBinding computes, and a named owner and ordering for single consumption. The maturity claim route works as a request claim, not as registry content, until the self-declared provenance digest gap closes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012sgN4GH5ZYT8pJVkCR6dcP Assistant: claude-code Assistant-Model: opus Assistant-Process: 4014348@bnt-lap001 Assistant-Session: a993abda-65a0-4ea8-8ccd-0fcd78c92ac0 |
||
|---|---|---|
| .claude/rules | ||
| .forgejo/workflows | ||
| .github/workflows | ||
| .repo-manager | ||
| charts/flex-auth | ||
| cmd/flex-auth | ||
| decisions | ||
| deploy | ||
| docs | ||
| examples | ||
| 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.