# 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.md` files. 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 |

---

## 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 interface
- `ops-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 by `railiance-platform`)
- `railiance-apps` — applications
- `ops-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).