net-kingdom/history/2026-08-23-scope-intent-gap-assessment.md

NetKingdom scope-to-intent gap assessment

Date: 2026-08-23 Assessment target: SCOPE.md against INTENT.md Status: current-state assessment, not an architectural decision

Executive assessment

NetKingdom is coherent and useful today as a security canon, integration-architecture, and bootstrap/reference-tooling repository. Its strongest delivered surfaces are bootstrap identity and custody, a provider-neutral identity contract, live lightweight SSO/MFA integration, explicit user/tenant/credential boundaries, and executable conformance checks.

It is not yet the dynamic, self-optimizing, full-circle security platform described by INTENT.md. In particular, it does not yet select and execute a scenario to turn-key readiness, run a closed audit-to-policy improvement loop, or provide enterprise federation. Those remain valid intent; they must not be represented as current capability.

The revised SCOPE.md therefore narrows current claims without narrowing the mission. NetKingdom owns security semantics, contracts, bootstrap/reference 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 2026-08-23.

Same-day implementation follow-up

NK-WP-0030 subsequently implemented the first bounded G1 increment: proposed Security Scenario Composition v0.1 canon, a fail-closed plan-only composer, and a real C0 local-identity declaration and reference scenario. This establishes deterministic provider pins, trust ordering, responsibility mapping, and readiness handoff without executing provider actions. KeyCape subsequently published conformant owner declarations for C1 and C2b. NetKingdom's checked-in reference now composes them in trust order and preserves their responsibility map without claiming C2a. G1 remains open beyond this bounded increment because the composer neither executes the provider entry points nor closes their readiness obligations into verified turn-key state.

NK-WP-0031 subsequently implemented the first bounded G2 increment: proposed Posture Feedback v0.1 canon and a deterministic evaluator that turns explicit review dates, evidence freshness, implemented-but-unevidenced controls, and declared gaps into owner-routed remediation proposals. Time is an explicit input; missing ownership or freshness resolves to unknown; and the report forbids external, declaration, and policy writes. G2 remains open because the tool does not create work, change policy, close remediation, or consume runtime telemetry autonomously. Those powers require separate authority, rollback, and review decisions.