net-kingdom/docs/architecture/expanded-mode-admission-requirements.md

Expanded-mode federation admission requirements

Work: NK-WP-0011. Authority: accepted ADR-0009, decisions 1–8 and ADR-0015. This packet defines evidence required to start implementation. It does not admit a tenant, assign an issuer, or authorize a deployment.

Adoption trigger

All three fields must be supplied together, with an owner-attributed reference:

Required fact	Acceptance
Named tenant	Existing canonical tenant identifier, confirmed by tenant-engine
Upstream IdP owner	Named responsible organization/person and supported upstream protocol
Federation need	Concrete login requirement that the lightweight issuer cannot meet

No qualifying trigger is recorded in the reviewed workplan. User count and interest in Keycloak do not satisfy ADR-0009. Until the trigger exists, T02–T09 remain waiting and the plan remains blocked.

Owner delivery requirements

After the trigger is accepted, obtain owner workplan/task references and dated, non-secret receipts for these deliverables. An owner name without acceptance and evidence is not delivery.

NK task	Dependency owner	Required deliverable and acceptance evidence
T02	railiance-platform + rapp-postgres	Named database consumer and selected catalog placement; isolation, governed credential route and exact ESO references; backup scope/retention and isolated database restore proof
T03	ADR-0015 package/runtime owner + railiance-platform	Explicit package ownership, immutable hostname/issuer, pinned image, declaration and reviewed rollout/rollback; exact workload identity/ESO role with least-privilege denied-operation evidence
T04	Upstream IdP owner + package owner + user-engine	Non-secret upstream metadata and governed secret references; tenant-scoped versioned claim/group mappings; pending JIT projection; ambiguity denial; federated login proof preserving issuer/subject account binding
T05	key-cape/package owner + access-engine	Per-IdP assurance trust mapping; AAL1 default; reviewed privileged step-up flow and assurance enforcement receipts; coordinate NK-WP-0042 and retain accepted IAM v0.3 until v0.4 acceptance
T06	package owner + key-cape + tenant-engine	One active issuer per tenant and discovery configuration; dedicated test-client admission; conformance result and coexistence/subject-binding evidence
T07	tenant-engine + access-engine + package owner	Canonical tenant/tier/issuer ownership, reserved platform boundary, subject-role vs tenant-capability separation; live role freshness for privileged decisions; tenant-admin cross-boundary denial evidence
T08	railiance-platform + package owner + audit-core	Protected export custody, off-host backup and isolated restore receipts; disabled-by-default break-glass with alert proof; owner-bound audit emission/retention/correlation contract and observed receipt
T09	tenant-engine + package/runtime owner	Tier from canonical IAM capability, immutable realm/issuer, preserved subjects/federated links; owner-executed isolated migration/login/rollback drill and per-tier database/credential/backup evidence

NetKingdom retains architecture and conformance ownership. Deployment YAML, provider configuration, database credentials and live operator work belong to their respective owners. No new owner task ID is invented before acceptance.

Conformance evidence limits

The existing executable suite is documented as IAM v0.2. Accepted v0.3 is additive and preserves v0.2 conformance; the existing checks cover the shared baseline, not every v0.3 tenant-capability carrying/freshness obligation. Record the suite/source version and separately prove tenant-role sourcing and privileged live freshness. Fixture passes are not live issuer acceptance.

Resume and close

Resume when the trigger and package/runtime owner are recorded. Replace each owner dependency with its accepted task reference and receipt; leave downstream tasks waiting until their prerequisites arrive. Finish only after the workplan's live login, isolation, recovery, audit and upgrade acceptance criteria pass.

Review: 2026-10-03. This admission packet is local contract preparation; T02–T09 implementation has not started.