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.