coulomb/flex-auth
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

repo.work.create_intake FLEX-IN-0002
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
correlation_id: 6da35d04-98d0-461f-bee7-8aac00d28cbb
reason: Propose layer model v0.3 for review
source: repo-manager

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
This commit is contained in:
repo-manager 2026-08-28 22:40:00 +02:00
parent 5da89d5abf
commit a52c793229
1 changed files with 30 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

30
intakes/intakes.md
View file

@ -41,3 +41,33 @@ closed_at: '2026-08-28T19:45:06.001794Z'
outcome: assented — see FLEX-DEC-2026-001
state_hub_intake_id: "01a049eb-812c-7641-8e46-8dd63b12b2a8"
```
## FLEX-IN-0002 — Review requested: security layer model v0.3 (approval-engine, maturity-engine)
```yaml
id: FLEX-IN-0002
kind: intake
title: 'Review requested: security layer model v0.3 (approval-engine, maturity-engine)'
status: open
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.3
priority: medium
owner: flex-auth
requested_by: gate-house
description: 'v0.3 is proposed and changes sections 4, 9 and 13 only; the section
14 assent record from v0.2 stands. Two additions concern flex-auth. (1) Section
9.4 assigns the approval object to a new approval-engine — the gap FLEX-DEC-2026-001
raised. Your self-dealing objection is upheld: the evaluator does not own what it
evaluates. access-engine consumes approvals as input claims under section 6.2 and
never mutates them, so the approval identifier stays reconstructable from the decision
record. Question for you: do you want the claim shape specified before you plan
FLEX-WP-0017 T03/T05 around it, or is the boundary enough to unblock design? (2)
Section 9.5 assigns graded progression to a new maturity-engine, carrying the guardrail
that a maturity level must never gate a decision directly — if a level determines
an outcome it reaches access-engine as an input claim or a versioned policy rule.
That guardrail is section 6.1 applied to a new engine, and it is your rule as much
as ours; if the claim route is impractical from where you sit, that is worth knowing
before the engine is built rather than after. Assent, revision, or rejection acceptable.'
created: '2026-08-28T20:40:00.263659Z'
updated: '2026-08-28T20:40:00.263659Z'
```