tools, and cross-repository composition. The runtime services and managed
deployment packages remain with their implementation owners.
## Evidence basis
The assessment used the repository state and work records current on the date
above, especially:
-`INTENT.md` and `docs/platform-identity-security-architecture.md`
-`canon/standards/` and their executable schemas/validators
-`docs/responsibility-map.md` and ADR-0006 through ADR-0015
-`local-identity/`, `tools/security-bootstrap-console/`, and other validators
under `tools/`
-`sso-mfa/` deployment/integration assets and runbooks
- current and archived workplans, including NK-WP-0001/0002/0006/0011/0012,
NET-WP-0015 through NET-WP-0020, and NK-WP-0022/0027/0028
- the 2026-07-02 greenfield OpenBao proof in `history/`
## Assessment by intent principle
| Intent principle | Current evidence | Assessment | Material gap |
| --- | --- | --- | --- |
| Bootstrap First | `local-identity`, SOPS/age helpers, bootstrap agent, guarded console, and a greenfield OpenBao init/unseal proof | Substantially implemented as a reference path | Production HA/auto-unseal, attended ceremony, restore, and break-glass evidence are not all closed; legacy retirement remains date-gated in NK-WP-0022 |
| Identity is the Control Plane | IAM Profile v0.3, lightweight KeyCape integration, explicit tenant roles/grouping, workload identity, user/tenant boundaries, and flex-auth caller identity | Strong contract layer with meaningful live integration | Authoritative identity/zone coverage is incomplete across the estate; some operational paths still rely on compatibility credentials; expanded enterprise identity is absent |
| Open & Replaceable Core | Provider-neutral OIDC contract, conformance tests, explicit provider boundaries, and open components | Contractually strong, operationally partial | Replacement/transition has not been proven with a second production issuer; Keycloak coexistence and migration rules remain backlog work |
| Progressive Capability Expansion | C0-C6 ladder is defined; C0-C3 have delivered components; C4 has partial integration | Architecture is clear and lower tiers are useful | There is no executable tier/scenario composer, C4 is not demonstrated end-to-end for the whole estate, and C5 is not delivered |
| Self-Optimization | Posture declarations, validators, evidence freshness, workplan/state reconciliation, and drift surfacing | Early feedback mechanisms only | No closed telemetry-to-policy loop, learned policy adaptation, autonomous mitigation, or bounded kaizen-agent control loop exists |
| Minimize Threat Exposure | Default-deny boundaries, scoped identities, short-lived token patterns, OpenBao custody, non-secret evidence, and separation of platform root from tenant admin | Strong design and several live proofs | Durable audit, restore, dual-control/break-glass evidence, remaining static credentials, and complete zone/data-classification adoption remain open |
| Meta-Orchestration | Playbook Capability Contract and responsibility map define selection, parameter, trust-state, and ownership semantics | Contract layer implemented | No turn-key scenario orchestrator composes and drives the selected playbooks; reef carrier/provider authority needed by NK-WP-0027 is unresolved |
| Kaizen-agent operating model | File-first workplans, State Hub reconciliation, freshness dates, cross-repo routing, and agent-executed verification | Process foundation exists | No standing, explicitly assigned and scheduled workforce covers recurring rotation, audit, drift, restore, and remediation duties end-to-end |
## Prioritized gaps
### G1 — Executable meta-orchestration
The largest mission gap is between a declared playbook contract and an
operator-selectable scenario that reaches verified, ready-to-run state.
NetKingdom can describe responsibilities and capability inputs, but it does not
yet compose a requested C0-Cn target, resolve providers, execute Railiance
playbooks, and verify the resulting trust state as one bounded workflow.
Next evidence should be one narrow scenario—preferably the already proven
lightweight identity path—expressed as capability declarations, selected by a
small composer, executed by owning repositories, and closed by machine-readable
readiness evidence.
### G2 — C6 feedback and continuous evidence
Posture and evidence records can expose drift, but no supported loop turns that
signal into a reviewed policy or remediation change. A safe first C6 increment
should be deterministic rather than self-learning: freshness expiry or a failed
posture assertion opens owner-scoped work, proposes a bounded remediation, and
requires evidence before closure. Autonomous policy mutation should remain out
of scope until authority, rollback, and human-review boundaries are explicit.
### G3 — Enterprise federation and provider transition
NK-WP-0011 remains backlog. Until a Keycloak/enterprise-IdP path and coexistence
rules are implemented and conformance-tested, this repository provides the
expanded-mode architecture only. It must not advertise enterprise Keycloak,
LDAP/Entra federation, SAML brokering, or multi-realm operation as delivered.
### G4 — Runtime/package authority convergence
The repository still contains Kubernetes assets with operational history while
ADR-0015 assigns managed application packages to `rapp-user-engine`,
`rapp-tenant-engine`, and analogous package owners. Each retained manifest must
be classified as canonical reference, test fixture, migration input, or retired
asset. Apply authority should become unambiguous without discarding useful
evidence.
### G5 — Ratification and estate adoption of newer canon
Tenancy Posture v0.1 and Security Zones v0.1 remain proposed. Their local schema
and validation surfaces exist, but adoption depends on external declarations,
zone-engine semantic ownership, reef carrier resolution, and an InfoTech Canon
classification ruling. NK-WP-0027 tracks these dependencies. Missing or
ambiguous authoritative membership must continue to resolve to `unknown`, never
to an inferred permissive zone.
### G6 — Production custody, audit, and recovery evidence
The bootstrap/custody arc is technically substantial, including a live
greenfield OpenBao proof. Production readiness still needs durable evidence for
HA/auto-unseal or attended ceremony, audit shipping and restoration,
break-glass review, credential rotation, and removal of superseded compatibility
credentials. NK-WP-0022 carries the immediate date-gated retirement work.
### G7 — Operator learning and repeatability
NK-WP-0009 remains backlog. Tutorials are not the primary architectural gap,
but concise operator paths are necessary if the capability ladder is to be
selectable and repeatable by humans and agents other than its original authors.
## Scope ruling
Until G1 and G2 are delivered, the repository should describe itself as:
> NetKingdom's canonical security architecture, integration boundary, and
> bootstrap/reference implementation.
It should not describe itself as an already self-optimizing platform, a general
deployment repository, or the implementation owner of Keycloak, KeyCape,
flex-auth, OpenBao, user-engine, tenant-engine, Kubernetes, or Railiance
packages. `INTENT.md` should remain unchanged: it is an appropriately ambitious
destination and already labels itself aspirational.
## Work-state conclusion
At assessment time there was no locally actionable ready/active implementation
task beyond this reconciliation. Remaining work was blocked on external canon
or provider inputs (NK-WP-0027), date-gated (NK-WP-0022), or explicitly backlog
(NK-WP-0009 and NK-WP-0011). This is not an assertion that the intended system
is complete; it is a statement about the executable queue in this repository on
