2026-08-28 21:30:03 +02:00
|
|
|
|
# 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'
|
2026-08-28 21:45:06 +02:00
|
|
|
|
status: closed
|
2026-08-28 21:30:03 +02:00
|
|
|
|
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 NetKingdom’s 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'
|
2026-08-28 21:45:06 +02:00
|
|
|
|
updated: '2026-08-28T19:45:06.001794Z'
|
2026-08-28 21:45:04 +02:00
|
|
|
|
notes:
|
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001
flex-auth answers gate-house's assent request on the three items ratified in
GH-DEC-2026-001, following the estate precedent that a boundary is drawn on
review by the other side.
Assent to all three, with one conformance debt flex-auth accepts as its own and
two conditions on the rename:
- Engine framing and sole decision point: assent. flex-auth cannot hold this
boundary against zone-engine and decline it as a general rule. But standard
section 6 also binds flex-auth: DecisionProvenance carries no registry
snapshot digest, so a decision that turned on registry content cannot be
replayed from its own provenance. Recorded as a known non-conformance rather
than claimed as conformance.
- access-engine rename: assent to the name, not to execution. Repository
identity and runtime identity must rename in separate revertible steps —
since FLEX-WP-0016 the enforcing ops-warden pin binds tokens to the
protected-system name, so a single-step rename 401s every warden sign,
including the certificate the ops-bridge tunnels depend on. FLEX-WP prefix
ownership stays with the repository.
- Authoring/evaluation split: assent, with the section 6 test applied
symmetrically — a gate-house authority ceiling that determines an outcome
reaches the decision as an input claim or as a rule in the versioned policy
package, so its application stays reconstructable from the decision record.
FLEX-WP-0017-T03 stays wait: the design half re-routes to gate-house, the
durable storage half remains unowned and is raised as an engine gap under
section 5.
Decision id follows the canon scheme {PREFIX}-DEC-YYYY-NNN.
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
2026-08-28 21:47:06 +02:00
|
|
|
|
- content: 'Answered by FLEX-DEC-2026-001 (decisions/decisions.md): assent to all three
|
2026-08-28 21:45:04 +02:00
|
|
|
|
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'
|
2026-08-28 21:45:06 +02:00
|
|
|
|
closed_at: '2026-08-28T19:45:06.001794Z'
|
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001
flex-auth answers gate-house's assent request on the three items ratified in
GH-DEC-2026-001, following the estate precedent that a boundary is drawn on
review by the other side.
Assent to all three, with one conformance debt flex-auth accepts as its own and
two conditions on the rename:
- Engine framing and sole decision point: assent. flex-auth cannot hold this
boundary against zone-engine and decline it as a general rule. But standard
section 6 also binds flex-auth: DecisionProvenance carries no registry
snapshot digest, so a decision that turned on registry content cannot be
replayed from its own provenance. Recorded as a known non-conformance rather
than claimed as conformance.
- access-engine rename: assent to the name, not to execution. Repository
identity and runtime identity must rename in separate revertible steps —
since FLEX-WP-0016 the enforcing ops-warden pin binds tokens to the
protected-system name, so a single-step rename 401s every warden sign,
including the certificate the ops-bridge tunnels depend on. FLEX-WP prefix
ownership stays with the repository.
- Authoring/evaluation split: assent, with the section 6 test applied
symmetrically — a gate-house authority ceiling that determines an outcome
reaches the decision as an input claim or as a rule in the versioned policy
package, so its application stays reconstructable from the decision record.
FLEX-WP-0017-T03 stays wait: the design half re-routes to gate-house, the
durable storage half remains unowned and is raised as an engine gap under
section 5.
Decision id follows the canon scheme {PREFIX}-DEC-YYYY-NNN.
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
2026-08-28 21:47:06 +02:00
|
|
|
|
outcome: assented — see FLEX-DEC-2026-001
|
2026-08-28 21:49:29 +02:00
|
|
|
|
state_hub_intake_id: "01a049eb-812c-7641-8e46-8dd63b12b2a8"
|
2026-08-28 21:30:03 +02:00
|
|
|
|
```
|
2026-08-28 22:40:00 +02:00
|
|
|
|
|
|
|
|
|
|
## 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)'
|
2026-08-29 02:42:14 +02:00
|
|
|
|
status: closed
|
2026-08-28 22:40:00 +02:00
|
|
|
|
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'
|
2026-08-29 02:42:14 +02:00
|
|
|
|
updated: '2026-08-29T00:42:14.888434Z'
|
2026-08-29 02:42:14 +02:00
|
|
|
|
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'
|
2026-08-29 02:42:14 +02:00
|
|
|
|
closed_at: '2026-08-29T00:42:14.888434Z'
|
|
|
|
|
|
outcome: assented with findings — see FLEX-DEC-2026-002
|
2026-08-29 02:45:11 +02:00
|
|
|
|
state_hub_intake_id: "01a04afa-307b-7e9e-b210-261badabcec7"
|
2026-08-28 22:40:00 +02:00
|
|
|
|
```
|