coulomb/net-kingdom
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(scope): reconcile capability with intent
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02929-244b-7391-b933-c04010e8eedb
This commit is contained in:
tegwick 2026-08-23 11:58:39 +02:00
parent 2c8a296c3a
commit 6204184930
4 changed files with 351 additions and 117 deletions
Download patch file Download diff file Expand all files Collapse all files

254
SCOPE.md
View file

@ -1,168 +1,188 @@
# SCOPE # SCOPE
> This file helps you quickly understand what this repository is about, > This file describes the repository's current capability and authority.
> when it is relevant, and when it is not. > `INTENT.md` remains the aspirational direction; the difference is assessed in
> It is intentionally lightweight and may be incomplete. > `history/2026-08-23-scope-intent-gap-assessment.md`.
--- ---
## One-liner ## One-liner
Platform domain for NetKingdom identity and security services — owns the IAM Profile specification, SSO/MFA platform (Keycloak), and bootstrap local-identity infrastructure for Kubernetes deployments. Canonical security architecture and bootstrap/reference implementation for
NetKingdom: defines identity, tenancy, workload-zone, credential, and
orchestration contracts; supplies conformance and bootstrap tooling; and
coordinates their realization across KeyCape, flex-auth, OpenBao, and
Railiance.
--- ---
## Core Idea ## Core Idea
NetKingdom is a self-optimizing security platform for Kubernetes-based IT infrastructure. This repo owns identity at the platform level: the NetKingdom IAM Profile specification (the versioned OIDC/PKCE contract all applications target), the enterprise Keycloak-based SSO/MFA platform, and a lightweight file-based local-identity service for bootstrap environments before the full cluster is available. This repository is NetKingdom's security canon and integration hub. It defines
provider-neutral contracts and responsibility boundaries, provides executable
validators and bootstrap/reference tooling, and records how independently owned
services compose into a security control plane.
It does not own every runtime that realizes those contracts. Service
implementations, Kubernetes infrastructure, platform data services, and managed
deployment packages remain in their respective repositories. The dynamic,
self-optimizing platform in `INTENT.md` is the direction of travel, not a claim
about the current implementation.
--- ---
## In Scope ## In Scope
- NetKingdom IAM Profile specification (versioned OIDC/PKCE contract; ### Canon and architecture
canonical spec: `canon/standards/iam-profile_v0.3.md`)
- SSO/MFA Platform: Keycloak with LDAP/Entra federation, enterprise identity (NK-WP-0001, finished) - NetKingdom IAM Profile v0.3: the accepted provider-neutral OIDC/PKCE,
- Local Identity: file-based user store + minimal OIDC server for bootstrap phase (NK-WP-0002, finished) principal, tenant, workload-identity, assurance, and flex-auth input contract.
- User Engine Boundary Contract: source-of-truth, membership, - Accepted user-engine and tenant-engine boundary contracts.
application-onboarding, projection, authorization, and audit contracts for - Credential Management Standard v0.2 and the platform-root/OpenBao custody
`user-engine` integration (`canon/standards/user-engine-boundary-contract_v0.1.md`) model.
- Security bootstrapping: credential management, SOPS/age integration, - Playbook Capability Contract v0.1 for the boundary between NetKingdom
platform-root custody, OpenBao runtime secret authority selection/parameterization and Railiance execution.
- OpenBao init/unseal custody models (NET-WP-0020): `sops-held-automation` - Tenancy Posture v0.1 and Security Zones v0.1 proposed standards, their schemas,
(lab, unattended greenfield rebuilds via `creds-bootstrap-agent` Phase 7b), validators, evidence rules, and publication stewardship. Zone semantics are
`attended-ceremony` (production, runbook + non-secret evidence records), and owned by `zone-engine`; NetKingdom owns their canon publication.
`auto-unseal-transit` (production HA; seal stanza lives in - Architecture decisions and the cross-repository responsibility map for
railiance-platform) — all gated by the security bootstrap console and a identity, authorization, credentials, tenancy, and bootstrap trust.
lab/production deployment profile
- Security bootstrap console (`tools/security-bootstrap-console/`): custody ### Executable reference and verification surfaces
gates, roster, evidence validators, refuse-live-init boundary
- Architectural decisions (DECISIONS.md): identity source, secrets, GitOps, bootstrap user store - `local-identity/`: minimal file-backed OIDC identity for bootstrap,
development, test, and sandbox use.
- IAM Profile, playbook-capability, tenancy-posture, custody, evidence, and
bootstrap-policy validators.
- `tools/security-bootstrap-console/`: guarded platform-root and OpenBao
bootstrap workflow, including refusal of unsafe live initialization.
- SOPS/age bootstrap integration, credential-generation and rotation helpers,
and documented attended, automated-lab, and auto-unseal custody paths.
- Reference and migration-stage manifests/runbooks for the current lightweight
identity stack: KeyCape, Authelia, LLDAP, and privacyIDEA.
### Integration and meta-orchestration contracts
- Capability selection, safe parameterization, trust-state requirements, and
responsibility assignment across Railiance playbooks.
- User/tenant onboarding boundaries, issuer/client registration patterns,
caller identity, workload identity, authorization inputs, and audit evidence.
- Cross-repository workplans and decision records needed to converge security
providers without absorbing their implementations into this repository.
--- ---
## Out of Scope ## Authority Boundaries
- Kubernetes runtime concerns → railiance-cluster This repository owns security semantics and composition rules. It does not own:
- Platform services (PostgreSQL, storage, caches) → railiance-platform
- Application deployments → railiance-apps - KeyCape's implementation (`key-cape`)
- KeyCape implementation details → key-cape - authorization service implementation or policy evaluation (`flex-auth` and
its PDP adapters)
- runtime secret-service deployment (`railiance-platform` / OpenBao)
- Kubernetes and host infrastructure (`railiance-cluster`,
`railiance-infra`)
- SSH certificate issuance or tunnels (`ops-warden`, `ops-bridge`)
- user or tenant service implementation (`user-engine`, `tenant-engine`)
- managed application packages (`rapp-*` repositories)
- generic platform data services such as PostgreSQL and storage
(`railiance-platform`)
The material under `sso-mfa/k8s/` includes live-proven integration history and
migration inputs. It is not blanket authority for managed runtime deployment.
ADR-0015 moves package/application ownership to the relevant `rapp-*`
repositories while NetKingdom retains the contracts and reference evidence.
---
## Current Capability
| Tier | Current repository/estate capability | Delivery state |
| --- | --- | --- |
| C0 — Bootstrap identity | Local OIDC identity, SOPS/age bootstrap, guarded credential workflow, and greenfield OpenBao init/unseal proof | Implemented as reference/bootstrap tooling |
| C1 — Lightweight SSO | IAM-profile-based KeyCape composition using Authelia and LLDAP | Live-proven integration; implementation externally owned |
| C2 — MFA/token authority | Authelia factors and privacyIDEA integration | Live-proven integration; implementation externally owned |
| C3 — Runtime secrets | OpenBao custody, bootstrap, policy, delivery, and recovery contracts | Integrated with an externally deployed runtime; production evidence remains gated |
| C4 — Fine-grained authorization | flex-auth caller identity and boundary integration | Partially delivered; full estate/PDP readiness is not established here |
| C5 — Enterprise federation | Keycloak/SAML/enterprise-IdP design | Backlog; not a current provided runtime capability |
| C6 — Self-optimizing security | Declarations, validators, evidence freshness, workplans, and drift surfacing | Early governance mechanisms only; no autonomous closed loop |
Current open work as of 2026-08-23 is either externally blocked, date-gated, or
explicit backlog: reef carrier/public-classification decisions in NK-WP-0027,
the NK-WP-0022 retirement gate, security tutorials in NK-WP-0009, and
enterprise federation in NK-WP-0011.
--- ---
## Relevant When ## Relevant When
- Setting up identity for a NetKingdom/Railiance deployment - Defining or reviewing identity, tenancy, workload-zone, credential, and
- Designing or using the guided security bootstrap experience security-composition canon.
- Applications need OIDC authentication; deciding between lightweight (KeyCape) and expanded (Keycloak) modes - Bootstrapping identity and trust before the normal platform is available.
- Bootstrap scenario: cluster not yet available, need minimal OIDC for dev/test/sandbox - Validating an IAM issuer, posture declaration, or Railiance capability
- Reviewing IAM Profile specification or architectural identity decisions declaration against NetKingdom contracts.
- Integrating KeyCape, flex-auth, OpenBao, user-engine, tenant-engine, or a
--- Railiance package across an explicit security boundary.
- Deciding which repository owns a security semantic, runtime, deployment, or
evidence obligation.
## Not Relevant When ## Not Relevant When
- Infrastructure provisioning (use railiance-infra) - Implementing a provider's internal service behavior: work in that service's
- Platform services configuration (use railiance-platform) repository.
- Application-level auth code (use the IAM Profile spec as reference only) - Provisioning hosts or Kubernetes: use `railiance-infra` and
`railiance-cluster`.
--- - Operating generic platform services: use `railiance-platform`.
- Shipping a managed application package: use its `rapp-*` repository.
## Current State - Treating the proposed Keycloak expanded mode or autonomous adaptation as an
already delivered feature.
- Status: active — core identity and bootstrap phases delivered; follow-on work
in backlog
- Implementation: NK-WP-0001 (SSO/MFA), NK-WP-0002 (local identity), the
security bootstrap arc (NET-WP-0015–0017, 0019), the IAM Profile spec
(NK-WP-0012), user-engine boundary contracts (NK-WP-0014), and OpenBao
unseal custody + SSH automation (NET-WP-0020) are all finished — see
`workplans/archived/`
- Backlog: NK-WP-0009 (security pattern tutorials) and NK-WP-0011 (enterprise
federation / SAML) — postponed, not yet started
- Stability: stabilizing — bootstrap/custody tooling is live-proven (greenfield
OpenBao init/unseal proof 2026-07-02); production custody models are gated
by evidence
- Usage: foundational authentication layer for all NetKingdom deployments
- Sister-repo maturity: [reuse.coulomb.social](https://reuse.coulomb.social)
federated capability registry
---
## How It Fits
- Upstream dependencies: KeyCape (lightweight IAM implementation), Authelia, Keycloak, LLDAP, privacyIDEA
- Downstream consumers: railiance (all Railiance deployments), applications targeting the NetKingdom IAM Profile
- Often used with: key-cape (lightweight mode), railiance-platform (identity services integration), railiance-cluster (deployed on Kubernetes)
---
## Terminology
- Preferred terms: NetKingdom IAM Profile, local identity, SSO/MFA platform, bootstrap, lightweight mode, expanded mode
- Also known as: "net-kingdom"
- Potentially confusing terms: "local identity" = file-based bootstrap store (not a full LDAP); "SSO/MFA platform" = production Keycloak deployment
---
## Related / Overlapping
- `key-cape` — lightweight IAM implementation (KeyCape orchestrates Authelia+LLDAP+privacyIDEA)
- `railiance-platform` — net-kingdom identity services integrate at the platform services layer
--- ---
## Provided Capabilities ## Provided Capabilities
```capability ```capability
type: security type: governance
title: NetKingdom IAM Profile specification title: NetKingdom security canon
description: Versioned OIDC/PKCE contract that all NetKingdom applications target — canonical v0.2 defines discovery, PKCE, token, JWKS, tenant, principal-type, assurance, and flex-auth claim inputs. description: Provider-neutral IAM v0.3, user/tenant boundaries, credential, playbook-composition, tenancy-posture, and workload-zone standards with explicit ownership and conformance rules.
keywords: [iam, oidc, pkce, profile, specification, identity, authentication] keywords: [iam, oidc, tenancy, workload-identity, security-zones, credentials, canon]
``` ```
```capability ```capability
type: security type: validation
title: SSO/MFA platform (Keycloak) title: Security contract conformance
description: Enterprise-grade Keycloak-based SSO with LDAP/Entra federation, MFA, and full OIDC/PKCE support for production deployments. description: Executable validation for IAM Profile issuers, playbook capability declarations, tenancy posture, bootstrap custody, and non-secret evidence records.
keywords: [sso, mfa, keycloak, ldap, entra, federation, oidc, enterprise] keywords: [validation, conformance, iam, posture, evidence, playbooks]
``` ```
```capability ```capability
type: security type: tooling
title: OpenBao unseal custody models and bootstrap automation title: Guarded security bootstrap
description: Three gated init/unseal custody models — SOPS-held automation for unattended lab rebuilds (greenfield-proven), attended ceremony with non-secret evidence records for production, and transit/KMS auto-unseal for production HA — enforced by the security bootstrap console and a lab/production deployment profile. description: Local bootstrap identity plus SOPS/age and OpenBao custody workflows that establish trust while refusing unsafe or unevidenced live initialization.
keywords: [openbao, unseal, custody, bootstrap, sops, age, ceremony, transit, auto-unseal, console] keywords: [bootstrap, local-identity, openbao, sops, age, custody, recovery]
``` ```
```capability ```capability
type: security type: governance
title: Bootstrap local identity service title: Security meta-orchestration boundary
description: Minimal file-based OIDC server for environments where the full cluster is not yet available — covers dev, test, and sandbox bootstrapping scenarios. description: Contracts and responsibility maps for selecting and parameterizing externally executed Railiance security capabilities without reimplementing their deployment mechanics.
keywords: [bootstrap, local-identity, oidc, minimal, dev, sandbox] keywords: [meta-orchestration, railiance, responsibility, capability, trust-state]
``` ```
--- ---
## Getting Oriented ## Getting Oriented
- Start with: `wiki/` (specifications and decisions), `DECISIONS.md` (key - Direction: `INTENT.md`
architectural choices D1–D5) - Current-vs-intended assessment:
- Key files / directories: `docs/platform-root-custody.md`, `sso-mfa/` `history/2026-08-23-scope-intent-gap-assessment.md`
(SSO/MFA platform + bootstrap scripts), `local-identity/`, - Canon: `canon/standards/`, `canon/schemas/`, and `docs/adr/`
`tools/security-bootstrap-console/`, `workplans/` (finished plans in - Architecture and ownership: `docs/platform-identity-security-architecture.md`
`workplans/archived/`) and `docs/responsibility-map.md`
- Backlog entry points: `workplans/NK-WP-0009-netkingdom-security-pattern-tutorials.md` - Bootstrap/custody: `docs/platform-root-custody.md`,
and `workplans/NK-WP-0011-enterprise-federation-saml.md`; finished context
in `workplans/archived/`
- User-domain boundary contract:
`canon/standards/user-engine-boundary-contract_v0.1.md`
- User-engine integration assessment (intent/scope fit, gaps, and recommendations):
`docs/user-engine-netkingdom-integration-assessment.md`
- Bootstrap/custody entry points:
`docs/platform-root-custody.md`,
`docs/security-bootstrap-use-cases.md`, `docs/security-bootstrap-use-cases.md`,
`docs/openbao-unseal-custody-models.md` (three custody models + deployment `docs/openbao-unseal-custody-models.md`, and
profile), and `docs/openbao-attended-ceremony-runbook.md` (production `tools/security-bootstrap-console/`
ceremony); history of the custody/bootstrap arc in `workplans/archived/` - Executable surfaces: `local-identity/`, `tools/iam-profile-conformance/`,
(NET-WP-0015–0017, 0019) and `tools/playbook-capability-contract/`, and `tools/tenancy-posture/`
`workplans/NET-WP-0020-openbao-unseal-custody-and-ssh-automation.md` - Work state: `.custodian-brief.md` and `workplans/`

5
WORK-RECORDS.md
View file

@ -22,6 +22,7 @@
| workplan | NK-WP-0026 | finished | — | workplans/NK-WP-0026-flex-auth-caller-identity-rollout.md | | workplan | NK-WP-0026 | finished | — | workplans/NK-WP-0026-flex-auth-caller-identity-rollout.md |
| workplan | NK-WP-0027 | blocked | — | workplans/NK-WP-0027-reef-placement-reconciliation.md | | workplan | NK-WP-0027 | blocked | — | workplans/NK-WP-0027-reef-placement-reconciliation.md |
| workplan | NK-WP-0028 | finished | — | workplans/NK-WP-0028-canon-publication-and-grouping-semantics.md | | workplan | NK-WP-0028 | finished | — | workplans/NK-WP-0028-canon-publication-and-grouping-semantics.md |
| workplan | NK-WP-0029 | finished | — | workplans/NK-WP-0029-scope-and-intent-reconciliation.md |
| task | ADHOC-2026-07-02-T01 | done | — | workplans/ADHOC-2026-07-02.md | | task | ADHOC-2026-07-02-T01 | done | — | workplans/ADHOC-2026-07-02.md |
| task | ADHOC-2026-07-02-T02 | done | — | workplans/ADHOC-2026-07-02.md | | task | ADHOC-2026-07-02-T02 | done | — | workplans/ADHOC-2026-07-02.md |
| task | ADHOC-2026-08-14-T01 | done | — | workplans/ADHOC-2026-08-14.md | | task | ADHOC-2026-08-14-T01 | done | — | workplans/ADHOC-2026-08-14.md |
@ -89,5 +90,9 @@
| task | NK-WP-0028-T02 | done | — | workplans/NK-WP-0028-canon-publication-and-grouping-semantics.md | | task | NK-WP-0028-T02 | done | — | workplans/NK-WP-0028-canon-publication-and-grouping-semantics.md |
| task | NK-WP-0028-T03 | done | — | workplans/NK-WP-0028-canon-publication-and-grouping-semantics.md | | task | NK-WP-0028-T03 | done | — | workplans/NK-WP-0028-canon-publication-and-grouping-semantics.md |
| task | NK-WP-0028-T04 | done | — | workplans/NK-WP-0028-canon-publication-and-grouping-semantics.md | | task | NK-WP-0028-T04 | done | — | workplans/NK-WP-0028-canon-publication-and-grouping-semantics.md |
| task | NK-WP-0029-T01 | done | — | workplans/NK-WP-0029-scope-and-intent-reconciliation.md |
| task | NK-WP-0029-T02 | done | — | workplans/NK-WP-0029-scope-and-intent-reconciliation.md |
| task | NK-WP-0029-T03 | done | — | workplans/NK-WP-0029-scope-and-intent-reconciliation.md |
| task | NK-WP-0029-T04 | done | — | workplans/NK-WP-0029-scope-and-intent-reconciliation.md |
| intake | NK-IN-0001 | closed | blue | docs/intakes/activity-core-ops-sso-operators.md | | intake | NK-IN-0001 | closed | blue | docs/intakes/activity-core-ops-sso-operators.md |
| intake | NK-IN-0002 | closed | blue | docs/intakes/activity-core-ops-sso-operators.md | | intake | NK-IN-0002 | closed | blue | docs/intakes/activity-core-ops-sso-operators.md |

137
history/2026-08-23-scope-intent-gap-assessment.md Normal file
View file

@ -0,0 +1,137 @@
# 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.

72
workplans/NK-WP-0029-scope-and-intent-reconciliation.md Normal file
View file

@ -0,0 +1,72 @@
---
id: NK-WP-0029
type: workplan
title: "Reconcile repository scope with implemented capability and intent"
domain: infotech
repo: net-kingdom
status: finished
owner: codex
topic_slug: netkingdom
planning_priority: P1
created: "2026-08-23"
updated: "2026-08-23"
---
# NK-WP-0029 — Scope and intent reconciliation
Authorized by the operator after repository triage found no locally actionable
ready/active work beyond documentation reconciliation. This work corrects stale
delivery claims in `SCOPE.md` and preserves `INTENT.md` as the aspirational
direction while recording evidence-backed gaps under `history/`.
## Inventory current capability and authority
```task
id: NK-WP-0029-T01
status: done
priority: high
```
Reviewed current and archived workplans, standards, ADRs, architecture,
responsibility boundaries, bootstrap/reference implementations, validators,
deployment assets, and open State Hub work. Distinguished repository-owned
canon/tooling from externally owned runtime implementations and managed
packages.
## Rewrite repository scope
```task
id: NK-WP-0029-T02
status: done
priority: high
```
Replaced the stale identity-only scope and removed the incorrect claim that
enterprise Keycloak federation is delivered. Documented the current canon,
bootstrap/reference tooling, integration role, C0-C6 delivery state, runtime
authority boundaries, and remaining work gates.
## Assess current scope against intent
```task
id: NK-WP-0029-T03
status: done
priority: high
```
Added `history/2026-08-23-scope-intent-gap-assessment.md`, assessing every
`INTENT.md` principle and prioritizing gaps in executable meta-orchestration,
C6 feedback loops, federation, package authority, canon adoption, production
custody evidence, and operator repeatability.
## Verify and reconcile records
```task
id: NK-WP-0029-T04
status: done
priority: medium
```
Checked links and named repository paths, Markdown whitespace, workplan
formatting, and repository tests applicable to the documented capabilities.
Reconciled the completed workplan with State Hub and the canonical registrar.