Add meta-orchestration layer to ADR-0007; deepen NetKingdom INTENT

- ADR-0007: refine (not overturn) the orchestration boundary with the
  two-layer model — Railiance executes parametrized playbooks, NetKingdom
  does meta-orchestration (scenario->playbook selection, parametrization,
  responsibility map). Add the playbook/capability-contract dependency as
  the prerequisite, analogous to the IAM Profile.
- INTENT.md: add "Why NetKingdom" (the kingdom metaphor: governed,
  defended, living/evolving, tended by its people); Principle 7
  (Meta-Orchestration over Re-Implementation); an Operating Model section
  (kaizen-agent workforce for recurring duties + change/improvement); and
  matching Direction-of-Evolution entries.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

INTENT.md

@@ -44,6 +44,27 @@ Traditional security approaches fail because they are:
 
 ---
 
+## Why "NetKingdom"
+
+The name is a deliberate metaphor, and a useful one: a kingdom is a
+**governed, defended, living territory that grows over time and is tended
+by its people**. NetKingdom is the same for an IT landscape:
+
+* **Governed** — identity is the control plane; who may do what, under
+  which conditions, is the law of the land.
+* **Defended** — security is the spine the whole territory is built on,
+  not a wall added afterward.
+* **Living and evolving** — the landscapes NetKingdom stands up are not
+  set once and frozen. They **grow capability by capability** and adapt as
+  the systems and threats around them change. "NetKingdom" names this
+  *dynamic evolvement* of the infrastructure as much as its initial setup.
+* **Tended by its people** — a kingdom that runs well is maintained
+  continuously. NetKingdom's "people" are **kaizen agents** (see
+  *Operating Model* below): hired to attend to the recurring duties that
+  keep the kingdom healthy and to carry out improvements and changes.
+
+---
+
 ## The Mission
 
 > *Where we are going.*
@@ -144,6 +165,42 @@ Instead of reacting to threats:
 
 ---
 
+### 7. Meta-Orchestration over Re-Implementation
+
+NetKingdom does not re-implement deployment mechanics. Execution lives in
+**Railiance playbooks** — parametrized, scenario-specific, with sensible
+defaults. NetKingdom performs **meta-orchestration**:
+
+* **select** the services and playbooks a scenario requires
+* **parametrize** them where tuning is warranted; otherwise trust defaults
+* **hold the responsibility map** — which element (a Railiance layer, an
+  external provider, a tenant-owned piece) owns what across the landscape
+
+NetKingdom is the architect and conductor; Railiance is the contractor and
+the instrument. (See ADR-0007 → *Meta-Orchestration Layer*.)
+
+---
+
+## Operating Model — A Kingdom Run by Kaizen Agents
+
+Once a reasonable setup is established, the kingdom is not left to run
+itself by accident. It is **staffed**. NetKingdom adopts a
+**kaizen-agentic** operating model: specialized agents are "hired" and
+assigned to the work the kingdom needs done on an ongoing basis —
+
+* **Recurring duties** that keep the kingdom healthy: readiness checks,
+  rotation, audit review, drift detection, backup/restore drills,
+  consistency reconciliation.
+* **Change and improvement work**, where agents matter even more:
+  introducing a new capability tier, onboarding a tenant, refining policy,
+  remediating findings — each carried out as inspectable, repeatable work.
+
+This is the human-and-agent embodiment of *Self-Optimization* (Principle
+5): the kingdom continuously improves because it has a workforce attending
+to it, not because a static configuration happens to hold.
+
+---
+
 ## What This Is (Conceptually)
 
 NetKingdom is:
@@ -182,6 +239,10 @@ It is the **security spine** that other systems attach to.
 NetKingdom is expected to evolve toward:
 
 * **Agent-aware security orchestration**
+* **A standing workforce of kaizen agents** tending the kingdom's
+  recurring duties and driving its improvements
+* **Meta-orchestrated, turn-key landscapes** composed from Railiance
+  playbooks per scenario
 * **Policy as code with feedback loops**
 * **Tight integration with DevSecOps workflows**
 * **Autonomous detection and mitigation patterns**

docs/adr/ADR-0007-security-orchestration-boundary.md

@@ -2,6 +2,7 @@
 
 **Status:** Accepted
 **Date:** 2026-05-18
+**Refined:** 2026-05-21 (meta-orchestration layer — see below)
 **Deciders:** Bernd Worsch, Codex
 
 ## Context
@@ -85,3 +86,57 @@ This avoids premature structure but leaves bootstrap and runtime trust
 transitions too dependent on operator memory. The accepted approach keeps
 the sequence explicit while leaving concrete deployment in the Railiance
 stack.
+
+## Refinement (2026-05-21): Meta-Orchestration Layer
+
+The original decision left "what NetKingdom does about orchestration"
+defined only negatively (it does not own deployment mechanics). This
+refinement names the positive role. It sharpens, and does not overturn,
+the accepted decision: execution stays in Railiance.
+
+There are two distinct layers:
+
+- **Railiance — execution orchestration (the "how").** A library of
+  scenario playbooks plus the tools that run them. Each playbook
+  provisions a slice of the landscape, ships **sensible defaults**, and
+  **exposes parameters** for tuning. Multiple playbooks exist for multiple
+  scenarios.
+- **NetKingdom — meta-orchestration (the "what" and "who").** NetKingdom
+  does not re-implement deployment mechanics. It (1) **selects** the
+  services and playbooks a given scenario requires, (2) **decides
+  parametrization** where tuning is warranted and otherwise relies on
+  playbook defaults, and (3) **holds the responsibility map** — which
+  element (a Railiance layer, an external provider, a tenant-owned piece)
+  owns what across the whole IT landscape.
+
+The relationship is architect ↔ contractor (or conductor ↔ players):
+NetKingdom composes the score and assigns parts; Railiance executes them.
+This is the same discipline used elsewhere — the IAM Profile is the
+contract while key-cape/Keycloak are implementations, and the State Hub is
+a read model over execution. Meta-orchestration is a **decide/compose**
+layer over Railiance's **execute** layer.
+
+This binds directly to the capability ladder
+(`docs/platform-identity-security-architecture.md` → *Capability
+Progression*): the ladder is the menu, a scenario selects a subset of
+tiers, and meta-orchestration is the act of binding that subset to
+playbooks + parameters + a responsibility map, producing a turn-key
+landscape.
+
+### New Dependency — Playbook / Capability Contract
+
+For NetKingdom to select and parametrize reliably, **Railiance playbooks
+must publish a declared interface**: the capability each playbook
+provisions, its parameters (with defaults and constraints), and the
+responsibility it claims. This catalog is the orchestration-layer analog
+of the IAM Profile. Without it, meta-orchestration composes against
+implicit behavior and breaks when a playbook changes. Establishing this
+contract is the prerequisite for any concrete meta-orchestration work.
+
+### Effect on the Future Repo Trigger
+
+Meta-orchestration logic now has a clear home (NetKingdom) regardless of
+whether a dedicated **execution**-orchestration repo is later created
+under the Future Repo Trigger above. A future repo, if created, would host
+reusable execution sequencing — not the scenario-composition and
+responsibility-mapping role, which remains NetKingdom's.