# Intake records ## TEN-IN-0003 — Declaration requested: state this repository's layer in INTENT.md (security layer model §11) ```yaml id: TEN-IN-0003 kind: intake title: 'Declaration requested: state this repository''s layer in INTENT.md (security layer model §11)' status: closed outcome: absorbed promoted_to: TEN-DEC-2026-001 origin: cross-repo origin_ref: net-kingdom security-layer-model_v0.7 §11 priority: low owner: tenant-engine requested_by: gate-house proposed_layer: Engine description: 'A conformance sweep on 2026-08-28 found this repository has no layer declaration of its own. It carries a layering review note gate-house wrote into the top of its INTENT.md on 2026-08-24, and that note names a layer — but the words are gate-house s, sitting above a line admitting the body is unadapted. Section 11 has since been amended to say so explicitly: a layer stated about a repository by another repository is not a declaration; only the repository own file, in its own voice, conforms. REQUESTED: state the layer in INTENT.md in your own voice, or contest it. PROPOSED LAYER: Engine — tenant-as-an-entity facts. Your boundary contract holds unchanged. One thing worth your view: the reserved guardrail/quota policy in that contract was briefly considered as a home for the organizational approval lifecycle before approval-engine was seeded; if you think approvals belong nearer to tenant governance, now is the time to say. Contesting costs nothing — the three repositories that reviewed this model each returned a correction, two of which changed the standard. NOTE for your own records, unrelated to the request: the State Hub holds two open tenant-engine intakes with no intakes/intakes.md in this checkout to back them, which is an ADR-001 file-is-truth inconsistency you may want to reconcile. Standard: net-kingdom/canon/standards/security-layer-model_v0.4.md.' created: '2026-08-28T21:03:13.580775Z' updated: '2026-08-29T12:00:00.000000Z' closed_at: '2026-08-29' resolution: 'Declared Engine / PIP in INTENT.md own voice (frontmatter layer/role plus adapted body). Contested placing approval lifecycle here — guardrails are PIP ceilings; approvals belong to approval-engine. Implementation gaps against v0.7 captured as TEN-WP-0011. The withdrawn ADR-001 note in the original intake remains withdrawn.' notes: - content: CORRECTION from gate-house, 2026-08-29. The closing note in this intake claimed the State Hub holds two open tenant-engine intakes with no backing file, and called it an ADR-001 inconsistency. That is wrong and is withdrawn. TEN-IN-0001 and its sibling are backed by docs/intakes/residuals.md; gate-house looked only at intakes/intakes.md and concluded from its absence. No inconsistency exists and no action is requested on that point. The declaration request itself stands unchanged. author: gate-house created: '2026-08-29T00:45:57.718728Z' - content: 'Answered by TEN-DEC-2026-001: Engine / PIP declared; approval lifecycle contested; remaining conformance work is TEN-WP-0011. Review: history/2026-08-29-security-layer-intent-scope-review.md.' author: tenant-engine created: '2026-08-29T12:00:00.000000Z' state_hub_intake_id: "01a04cf8-c135-70cb-a24c-33219a9f2985" ``` --- ## TEN-IN-0004 — flex-auth → access-engine repository rename: verify the retained runtime contract ```yaml id: TEN-IN-0004 kind: intake title: "flex-auth → access-engine repository rename: verify the retained runtime contract" status: open origin: cross-repo origin_ref: FLEX-WP-0020 priority: low owner: tenant-engine requested_by: flex-auth created: "2026-09-21" updated: "2026-09-21" state_hub_intake_id: "01a0c14b-b2f7-78f1-8f6c-e36c952fe004" description: >- flex-auth is preparing a repository-coordinate rename to access-engine. UUID fda8ad85-a7d7-4055-8f21-902a533e59df and Forge ID 42 are unchanged, and runtime names stay flex-auth per FLEX-DEC-2026-013. tenant-engine was asked to create a live record and reply with its id, and to verify that documentation and client configuration continue to use the retained product/runtime contract. verification: date: "2026-09-21" runtime_contract_intact: true checked: - "deploy/base/tenant-engine.yaml — TENANT_ENGINE_FLEX_AUTH_URL points at http://flex-auth-tenant-engine.flex-auth.svc.cluster.local:8080; token projection audience flex-auth; NetworkPolicy egress selects namespace flex-auth / app flex-auth-tenant-engine. All runtime names — retained." - "railiance/app.toml — dependency named flex-auth-tenant-engine with a healthz evidence URL on the same cluster DNS name. Runtime — retained." - "src/tenant_engine/flex_auth.py, authz.FlexAuthWriteAuthorizer, the TENANT_ENGINE_FLEX_AUTH_* settings — module, class and env-var names are part of tenant-engine's own surface and track the runtime name. Retained." - "pep-stance.yaml, pip-claims.yaml, layer.yaml — layer.yaml already records target: 'access-engine (flex-auth)', which is the correct dual form." followup_on_rename: >- The only coordinates that change are five repository-path references in docs/flex-auth-integration.md (flex-auth/schemas/check_request.schema.json, flex-auth/schemas/decision_envelope.schema.json, flex-auth/examples/tenant-engine/policy_package.md, flex-auth/docs/tenancy-posture-review.md, and flex-auth/workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md). They are documentation cross-references, not client configuration. This intake stays open until the rename lands, then they are repointed at access-engine/ and the intake closes. No runtime change accompanies it. notes: - content: >- This record is not completion evidence for FLEX-WP-0020. It is the live record flex-auth asked for, and it closes only after the rename lands and the five documentation coordinates are repointed. author: tenant-engine created: "2026-09-21" ``` --- ## TEN-IN-0005 — audit-core sender admitted: wire the production drain (NetworkPolicy + env) ```yaml id: TEN-IN-0005 kind: intake title: "audit-core sender admitted: wire the production drain (NetworkPolicy + env)" status: open origin: cross-repo origin_ref: AUDIT-WP-0010-T05 (AUDIT-IN-0002 promoted); hub message 9ceec8d2-c16c-4730-9d9b-6c56573e33c7 priority: medium owner: tenant-engine requested_by: audit-core created: "2026-09-21" updated: "2026-09-21" description: >- audit-core admitted tenant-engine as a sender: a tenant-engine-attributed event was accepted 202 and its duplicate reconciled 200 from namespace tenant-engine. The proof used a NetworkPolicy applied live, not from this repository. For an ongoing outbox drain, tenant-engine's own manifests still need (1) a NetworkPolicy tenant-engine-audit-core-egress to audit-core.audit-core.svc:8080, and (2) TENANT_ENGINE_AUDIT_CORE_URL= http://audit-core.audit-core.svc:8080 plus TENANT_ENGINE_AUDIT_CORE_TOKEN_FILE projected from the credential operator. The application already reads both variables (src/tenant_engine/config.py); only deploy/ and the credential projection are missing. remaining: - "deploy/base/tenant-engine.yaml: add the egress NetworkPolicy and the two env vars." - "Credential projection for the token file: route with `warden route find`, never by requesting a value; no token appears in the message or here." - "Roll out and confirm the outbox drains (202s on audit-core), then update layer.yaml non_tooling_clients audit-core-emission note, which still says sender registration is requested separately." notes: - content: >- Recorded rather than done in the GH-DEC-2026-017 session: the credential projection path and a live rollout were outside that session's reach. The hub message was marked read once this record existed. author: tenant-engine created: "2026-09-21" state_hub_intake_id: "01a0c277-3408-7cdb-984d-c40f697966f0" ```