access-engine/intakes/intakes.md
tegwick bb0cf85b42
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Retain synchronized work-record index and intake binding
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade
2026-10-11 18:37:44 +02:00

6.1 KiB
Raw Blame History

Intake records

FLEX-IN-0001 — Assent requested: Engine framing, access-engine rename, and the authoring/evaluation split

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 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'
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)

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"

FLEX-IN-0003 — Ordinary User Engine catalogue authorization contract

id: FLEX-IN-0003
kind: intake
title: Ordinary User Engine catalogue authorization contract
status: open
origin: cross-repo
origin_ref: USER-WP-0026-T03
priority: high
owner: access-engine
requested_by: user-engine
created: "2026-10-11"
updated: "2026-10-11"
description: >-
  Native one-app catalogue/readback is delivered under exact R1 approval
  b859698b-5d08-4da5-9599-4760c6a799f1. Genuine ordinary application.register
  denial remains. Return the supported User Engine application-management
  resource/action/verified-claim contract and narrowly scoped policy proposal,
  with source fixtures and exact runtime promotion/rollback candidate. State
  which application/tenant actions and principal classes are admitted; do not
  broaden self-service, grant maintenance identity human claims, or use
  catalogue membership as entitlement. Clarify that any T05 grant/revoke
  mutation changes its explicitly named owner fact under normal review,
  not a new generic mutation endpoint from the finished FLEX-WP-0035 readback.
  User Engine owns the protected write and broader signed-in acceptance.
  Source response can proceed autonomously; exact live policy rollout retains
  separate founder approval and real native negative/positive verification.
notes:
  - content: >-
      Existing provider readback contract and native R1 verification reviewed
      under FLEX-WP-ADHOC-2026-10-11-T01. No open Access workplan covers this
      distinct ordinary-management admission ask; FLEX35 is not reopened.
      Prepare response coordination case, not a foreign implementation clone.
    author: codex
    created: "2026-10-11"
state_hub_intake_id: "01a128c3-35b1-7f87-a8c6-af56e2660924"