Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 63291@bnt-lap001 Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
7.9 KiB
7.9 KiB
Intake records
TEN-IN-0003 — Declaration requested: state this repository's layer in INTENT.md (security layer model §11)
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
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)
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"