2026-05-21 02:05:37 +02:00
# 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.
2026-05-22 14:49:25 +02:00
The Playbook Capability Contract
(`canon/standards/playbook-capability-contract_v0.1.md` ) is the declared
interface NetKingdom uses for playbook selection and safe
parametrization.
2026-05-21 02:05:37 +02:00
---
## 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 |
2026-05-22 14:35:31 +02:00
| **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–
2026-05-21 02:05:37 +02:00
### `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 |
2026-05-22 14:35:31 +02:00
| **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 |
2026-05-21 02:05:37 +02:00
2026-05-22 19:50:12 +02:00
### `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 |
2026-06-03 10:33:31 +02:00
See `docs/user-engine-netkingdom-integration-assessment.md` for current implementation status, gaps, and recommendations on integration.
2026-05-21 02:05:37 +02:00
---
## Resource Kinds NetKingdom Orchestrates (cross-cutting)
Across the orchestrated repos, NetKingdom is responsible for the coherent,
cross-landscape management of:
2026-05-22 14:35:31 +02:00
- **Identities** — humans, service accounts, agents, groups, tenants,
and assurance evidence as normalized by the IAM Profile
2026-05-22 19:50:12 +02:00
- **User-domain facts** — account state, identity links, profile data,
preferences, memberships, and application catalog ownership as managed by
user-engine
2026-05-21 02:05:37 +02:00
- **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
2026-06-17 08:22:45 +02:00
- `ops-warden` — operational SSH certificate authority and access-routing
stewardship (see Operational SSH dependency below)
---
## Operational SSH dependency (`ops-warden`)
NetKingdom does not orchestrate ops-warden resources the way it orchestrates
identity or OpenBao mounts, but the platform **depends** on ops-warden for the
operational SSH credential lane:
| | |
| --- | --- |
| **Resources held** | SSH actor inventory, signing policy (TTL/principals), cert-side audit (`signatures.log` ) |
| **Repo owns** | `warden` CLI, cert_command contract, ops-ssh-wrapper, stewardship runbooks |
| **NetKingdom orchestrates** | Alignment with IAM actor model (`adm` /`agt` /`atm` ); credential-routing canon so workers reach OpenBao/flex-auth/key-cape for non-SSH needs; NK-WP-0009 tutorial linkage |
ops-warden is **post-minimal-bring-up** for platform bootstrap but **in scope**
for ongoing dev-worker and agent SSH access. It must not become a universal
secret broker — runtime secrets remain OpenBao; authorization remains flex-auth.
Canon: `ops-warden/INTENT.md` , `ops-warden/wiki/CredentialRouting.md` .
2026-05-21 02:05:37 +02:00
---
## 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
- `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).
