Frame NetKingdom as capability-driven turn-key IT-sec framework

Make the lightweight->expanded decision explicitly capability-driven (not
scale-driven) and capture the turn-key, capability-selectable framework
ambition.

- arch doc: add capability-driven rationale to the identity-mode choice;
  add a "Capability Progression (Start Small -> Enterprise)" ladder
  (C0 bootstrap -> C6 self-optimizing), including the C2a/C2b 2FA split
  (Authelia built-in vs privacyIDEA); answer the lightweight/expanded
  open question as capability-driven
- INTENT.md: recast Progressive Expansion as capability-driven with a
  no-structural-breaks guarantee; add capability-selection + turn-key
  orchestration to the mission and identity

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

INTENT.md

@@ -57,6 +57,10 @@ This means:
 * Security is **continuously adapting**, not periodically configured
 * Identity, access, and secrets form a **coherent control loop**
 * The system can **start small (bootstrap)** and grow into **enterprise-grade security**
+* You **select the capabilities you need**, and NetKingdom **places and
+  orchestrates** the right components to **turn-key readiness** — bringing
+  an IT landscape up safely and iteratively, like building a house to
+  handover condition
 * Security decisions become **observable, testable, and evolvable**
 
 ---
@@ -97,18 +101,24 @@ No hidden black boxes at the foundation.
 
 ---
 
-### 4. Progressive Expansion
+### 4. Progressive, Capability-Driven Expansion
 
-Security evolves in stages:
+Security evolves by **adding capabilities**, not by rebuilding. The path
+runs from bootstrap identity, through lightweight SSO and 2FA, runtime
+secrets and fine-grained authorization, up to enterprise federation SSO —
+but each step is taken **because a capability is needed, never because of
+user count**. Footprint and cost follow the capability choice; they do not
+drive it.
 
-1. **Bootstrap (local identity)**
-2. **Lightweight mode**
-3. **Expanded enterprise mode**
+Each tier must:
 
-Each stage must:
+* **be usable on its own** — you get value at every tier, not only at the top
+* **transition without structural breaks** — because every tier targets
+  the same IAM Profile contract, adding 2FA, secrets, authorization, or
+  federation *extends* the system rather than replacing it
 
-* be usable on its own
-* smoothly transition into the next
+> The concrete capability ladder (C0–C6) lives in
+> `docs/platform-identity-security-architecture.md` → *Capability Progression*.
 
 ---
 
@@ -141,9 +151,17 @@ NetKingdom is:
 * a **security control core**
 * a **reference architecture**
 * a **bootstrap path from zero → production-grade security**
+* a **capability-selectable, turn-key orchestrator** for identity,
+  authentication, and authorization — it places the right components and
+  brings them to ready-to-run state, then grows tier by tier
 * a **contract layer for identity and trust**
 * a **foundation for agent-aware security systems**
 
+This is the larger ambition: an **IT-security framework that builds IT
+landscapes safely and iteratively from scratch** — you choose how far up
+the capability ladder you need to go, and the system gets you there
+without structural breaks.
+
 ---
 
 ## What This Is Not

docs/platform-identity-security-architecture.md

@@ -124,6 +124,17 @@ key-cape is the lightweight profile implementation. Keycloak is the
 expanded-mode profile implementation. privacyIDEA provides MFA/token
 capabilities where the deployment mode uses it.
 
+The choice between lightweight and expanded mode is **capability-driven,
+not scale-driven**. key-cape comfortably serves large internal user
+populations; expanded-mode Keycloak is introduced when a *capability* is
+required that the lightweight stack does not provide — chiefly inbound
+enterprise federation and SAML brokering (Entra ID, Active Directory,
+generic SAML IdPs), complex multi-realm topologies, or delegated admin.
+A deployment climbs to expanded mode because it needs that capability,
+not because it has more users. The lower resource and operational
+footprint of the lightweight stack is a consequence of this rule, not the
+trigger for it. See **Capability Progression** below.
+
 Identity answers: who is this actor, how was the actor authenticated,
 what coarse claims are asserted, and what assurance evidence exists?
 
@@ -368,6 +379,48 @@ receive a scoped authorization decision, obtain only the allowed secret or
 short-lived credential, enforce the decision locally, and produce an
 auditable record without receiving platform-root authority.
 
+## Capability Progression (Start Small → Enterprise)
+
+NetKingdom is designed so an IT landscape can be brought up from nothing
+and hardened **one capability at a time**, with no structural rework when
+the next capability is added. Every tier is usable on its own and every
+tier issues or consumes the same NetKingdom IAM Profile, so adding a
+capability extends the system rather than replacing it.
+
+The progression is capability-keyed: you climb a tier when you need the
+capability it adds, never because of user count.
+
+| Tier | Capability added | Components added | You move here when… |
+| --- | --- | --- | --- |
+| **C0 — Bootstrap identity** | A local OIDC issuer + secret bootstrap so things can start safely before the platform exists | local-identity (NK-WP-0002), SOPS/age + agent bootstrap (NK-WP-0004/0005) | you have nothing yet and need dev/test/sandbox identity |
+| **C1 — Lightweight SSO** | Single-factor OIDC SSO over an internal directory | key-cape: Authelia + LLDAP | you want real SSO for internal users/services |
+| **C2a — 2FA (light)** | Second factor without a new heavy service | Authelia built-in TOTP / WebAuthn | you need 2FA but not enterprise token lifecycle |
+| **C2b — Token authority** | Hardware tokens, many token types, self-service enrollment, token lifecycle | privacyIDEA | you need an enterprise-grade MFA/token authority |
+| **C3 — Runtime secrets** | Dynamic, scoped, leased, audited secrets beyond bootstrap | OpenBao (NK-WP-0006) | workloads need runtime secrets, not just bootstrap material |
+| **C4 — Fine-grained authZ** | Policy-as-code decisions beyond coarse SSO claims | flex-auth + Topaz PDP (ADR-0006) | identity alone can no longer answer "may this actor do this?" |
+| **C5 — Enterprise federation** | Inbound Entra ID / AD / SAML brokering, multi-tenant realms | expanded-mode Keycloak (NK-WP-0011) | identities originate in an external enterprise IdP |
+| **C6 — Self-optimizing** | Audit feedback loops, drift surfacing, continuous adaptation | central audit sink + kaizen loops | the platform should improve and verify itself continuously |
+
+Two properties make this safe rather than just sequential:
+
+- **Usable at every tier.** C1 is a working SSO platform; you are never
+  forced to reach C5 to get value.
+- **No structural breaks.** Because every tier targets the IAM Profile
+  contract, 2FA (C2), runtime secrets (C3), fine-grained authorization
+  (C4), and federation (C5) are *additive*. Applications keep targeting
+  the same Profile; the implementation behind it grows.
+
+2FA illustrates the principle precisely: if you do not need a second
+factor, C2 is simply absent — the C1 stack runs without privacyIDEA. When
+you do, C2a (Authelia's built-in TOTP/WebAuthn) is the light option and
+C2b (privacyIDEA) is the enterprise token-authority option. Neither
+requires re-architecting C1.
+
+The intent is turn-key: NetKingdom selects, places, and orchestrates the
+components for the chosen tier set so the landscape reaches ready-to-run
+state — like building a house to handover condition — and can be extended
+to the next tier later without demolition.
+
 ## Production Readiness Checks
 
 Before the security platform is production-ready, each trust state needs
@@ -397,6 +450,8 @@ an explicit check:
 - Which tenant metadata is required before a service can register
   resources with flex-auth?
 - When does the platform switch from key-cape lightweight mode to
-  Keycloak expanded mode?
+  Keycloak expanded mode? (Answered as capability-driven — see Capability
+  Progression, tier C5. The remaining open part is the precise per-tenant
+  trigger and dual-issuer coexistence rule, owned by NK-WP-0011-T1.)
 - Does Topaz run centrally for the platform, per tenant, or per service
   for the first production deployment?