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>

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?