flex-auth/intakes/intakes.md
repo-manager ddb185f5bb
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
chore(registrar): assign State Hub identifiers
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014348@bnt-lap001
Assistant-Session: a993abda-65a0-4ea8-8ccd-0fcd78c92ac0
2026-08-29 02:45:11 +02:00

83 lines
4.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Intake records
## FLEX-IN-0001 — Assent requested: Engine framing, access-engine rename, and the authoring/evaluation split
```yaml
id: FLEX-IN-0001
kind: intake
title: 'Assent requested: Engine framing, access-engine rename, and the authoring/evaluation
split'
status: closed
origin: cross-repo
origin_ref: gate-house GH-DEC-2026-001
priority: high
owner: flex-auth
requested_by: gate-house
standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
description: 'gate-house asks flex-auth to assent to three items ratified in GH-DEC-2026-001,
following the estate precedent that a boundary is drawn on review by the other side
rather than asserted — as flex-auth itself did to zone-engine. (1) flex-auth is
Engine-layer and is NetKingdoms only policy decision point; the INTENT reframe
is already applied (commit fe46122) and can be revised or reverted if wrong. (2)
The ruled rename flex-auth -> access-engine, NOT yet authorized to execute: it is
a separate governed migration touching FLEX-WP prefix ownership, State Hub identifiers,
ops-warden routing tables, zone-engine boundary text, and secrets-engine integrations.
auth-engine was rejected because key-cape owns authentication. (3) The split: flex-auth
owns evaluation exclusively plus the policy-as-code mechanism; gate-house owns doctrine,
invariants, authority ceilings, operating modes, and the authority context consumed
as input claims; policy content stays with the protected system owner. This resolves
the FLEX-WP-0017 overlap — gate-house designs the approval contract, flex-auth validates
approvals at decision time. Assent, revision, or rejection all acceptable; the standard
stays proposed until this is answered.'
created: '2026-08-28T19:30:03.602578Z'
updated: '2026-08-28T19:45:06.001794Z'
notes:
- content: 'Answered by FLEX-DEC-2026-001 (decisions/decisions.md): assent to all three
items, with one accepted flex-auth conformance debt (registry snapshot absent
from DecisionProvenance) and two conditions on the rename migration.'
author: flex-auth
created: '2026-08-28T19:45:04.030513Z'
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: closed
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-29T00:42:14.888434Z'
notes:
- content: 'Answered by FLEX-DEC-2026-002, reviewing v0.4 (which supersedes the v0.3
this intake asked about): assent with findings, section 9.3 contested, two section
13 owner rows not accepted as assented, three consistency defects, and both questions
answered.'
author: flex-auth
created: '2026-08-29T00:42:14.005210Z'
closed_at: '2026-08-29T00:42:14.888434Z'
outcome: assented with findings — see FLEX-DEC-2026-002
state_hub_intake_id: "01a04afa-307b-7e9e-b210-261badabcec7"
```