7.6 KiB
Responsibility Map
The single place that records NetKingdom's orchestration relationships: which repositories NetKingdom orchestrates, which it merely depends on, and — for each orchestrated repository — which resources NetKingdom is responsible for managing across the landscape.
This is the deliberate counterpart to self-coherent intent: per ADR-0010, these relationships live here, not in the orchestrated repos'
INTENT.mdfiles. It complements ADR-0007 (meta-orchestration layer) and ADR-0010 (orchestration vs dependency, self-coherent intent).Status: living document. The classification is applied under the current scope and will be refined as interfaces and boundaries mature.
Current Scope
The current focus is the minimal setup of capabilities any IT landscape needs to be stood up and secured — compute/infra, cluster runtime, platform services, identity, and authorization. Repositories that provide application or business capabilities are out of scope for this map.
Classification Criterion
NetKingdom relates to other repositories in two distinct ways (ADR-0010):
- Orchestrated — the repo provides a service that holds resources NetKingdom must manage (users, roles, scopes, policies, credentials, infrastructure resources). The defining question: does the repo provide a service holding resources NetKingdom needs to orchestrate? → yes.
- Dependency — NetKingdom uses the repo as a tool to build its own interface, without managing resources the tool holds.
NetKingdom's role over orchestrated repos is meta-orchestration
(ADR-0007): it does not re-implement execution. It (1) selects the
services/playbooks a scenario needs, (2) parametrizes them where
tuning is warranted, and (3) holds responsibility for the resources
and the security boundaries — leaving execution mechanics to the repo.
The Playbook Capability Contract
(canon/standards/playbook-capability-contract_v0.1.md) is the declared
interface NetKingdom uses for playbook selection and safe
parametrization.
Orchestrated Repositories
For each: the resources it holds, what the repository owns (execution), and what NetKingdom is responsible for (meta-orchestration).
railiance-infra — infrastructure substrate
| Resources held | hosts/servers, OS hardening baseline, substrate access, at-rest bootstrap secret material, server inventory |
| Repo owns | provisioning, convergence, hardening, and baseline verification mechanics |
| NetKingdom orchestrates | whether the substrate layer is in a scenario; hardening/security parametrization; bootstrap secret-material placement policy; substrate access policy; the requirement that the baseline is verified before higher layers run |
railiance-cluster — cluster runtime
| Resources held | cluster runtime, networking/ingress, admission controls, cluster operators/addons, runtime access (kubeconfig) |
| Repo owns | runtime install, baseline configuration, and health-verification mechanics |
| NetKingdom orchestrates | whether the runtime layer is in a scenario; which security-relevant admission controls, operators, and addons are required; runtime access policy; the cluster-health gate before platform/identity deploy |
railiance-platform — shared platform services
| Resources held | databases, caches, runtime secret-custody authority, object storage, message brokers, backups |
| Repo owns | operating these stateful services to durability/recovery guarantees behind stable interfaces |
| NetKingdom orchestrates | which platform services a scenario needs; runtime secret-authority boundaries (platform-root vs tenant) and policies; backup/DR requirements; the identity-integration point; runtime-secret-trust readiness |
key-cape — identity
| Resources held | users, groups, sessions, MFA tokens, OIDC clients, the directory |
| Repo owns | the lightweight IAM implementation conforming to the NetKingdom IAM Profile v0.2 |
| NetKingdom orchestrates | the IAM Profile contract in canon/standards/iam-profile_v0.2.md; which identity/2FA capabilities are enabled (capability ladder C1–C2); user/group/role and OIDC-client provisioning policy; tenant and assurance requirements; identity-trust readiness and profile conformance |
flex-auth — authorization
| Resources held | roles, scopes, policies, protected-system registrations, resource/action vocabulary, decision/audit records |
| Repo owns | the authorization registry, control plane, and PDP adapters |
| NetKingdom orchestrates | the decision-envelope contract fed by IAM Profile v0.2 claims; platform vs tenant policy boundaries; which protected systems/resources are registered; policy-package import and governance; audit retention; authorization-trust readiness |
user-engine — user-domain/profile service
| Resources held | user account records, external identity links, profile and preference values, tenant/application/team memberships, application profile catalogs, projections, user-domain audit and lifecycle events |
| Repo owns | the headless user-domain service, profile/catalog resolver, projection APIs, local persistence, outbox events, and implementation tests |
| NetKingdom orchestrates | source-of-truth boundaries with IAM and flex-auth; tenant/platform administration boundaries; application onboarding bindings; membership synchronization rules; projection and claims-enrichment boundaries; audit correlation requirements |
See docs/user-engine-netkingdom-integration-assessment.md for current implementation status, gaps, and recommendations on integration.
Resource Kinds NetKingdom Orchestrates (cross-cutting)
Across the orchestrated repos, NetKingdom is responsible for the coherent, cross-landscape management of:
- Identities — humans, service accounts, agents, groups, tenants, and assurance evidence as normalized by the IAM Profile
- User-domain facts — account state, identity links, profile data, preferences, memberships, and application catalog ownership as managed by user-engine
- Roles, scopes, and policies — coarse claims through fine-grained authorization
- Secrets and credentials — bootstrap material and runtime secret authority
- Infrastructure resources — hosts, runtime, and platform services
These resource kinds, not the repositories that happen to hold them, are what the responsibility map exists to keep coherent.
Dependencies (used, not orchestrated)
NetKingdom uses these as tools to provide its own interface; it does not manage resources they hold, so they carry no NetKingdom references in their intent and do not appear in the resource map above.
railiance-fabric— tooling NetKingdom uses to provide an interfaceops-bridge— tunnel/transport tooling
Out of Scope (application/business capabilities or non-foundational tooling)
Recorded so the scoping decision is explicit and revisitable:
artifact-store— artifact/object-storage service consumed by applications (platform-level storage is held byrailiance-platform)railiance-apps— applicationsops-warden— operational SSH-credential tooling (post-setup, not part of minimal bring-up)railiance-enablement— developer/CI tooling- all other domain repositories (application/business capabilities)
Out-of-scope status here is a current-scope decision, not a permanent classification; some of these may become orchestrated as scope expands (e.g. object-storage credential vending, NK-WP-0007).