diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/audit-core/registry/capabilities/capability.audit.event-retain.md b/docs/assessments/netkingdom-2026-10-14/registry-before/audit-core/registry/capabilities/capability.audit.event-retain.md
new file mode 100644
index 0000000..a5055a5
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/audit-core/registry/capabilities/capability.audit.event-retain.md
@@ -0,0 +1,88 @@
+---
+id: capability.audit.event-retain
+name: Audit Event Retention
+summary: Collect, normalize, retain, and search audit events with integrity evidence across tenants.
+owner: audit-core
+status: production
+domain: infotech
+tags: [audit, retention, compliance]
+joins:
+  itc_cap: operations.audit
+  provision: data/capability/audit-core-operational.json
+  provision_maturity: D4
+
+external_evidence:
+  completeness:
+    level: C3
+    name: Substantial
+    confidence: medium
+    basis: live_receiver_and_restore_walk
+    satisfied_expectations:
+      - HTTP ingest through the backend contract
+      - append-only Postgres custody on platform-pg
+      - recovery cited to the live platform data.backup provision
+    broken_expectations:
+      - data.archive sink not provided
+    out_of_scope_expectations:
+      - application business audit semantics ownership
+      - booked-cost origination
+  reliability:
+    level: R2
+    confidence: medium
+    basis: failure_matrix_and_restore_walk
+    known_reliability_risks:
+      - single replica
+
+discovery:
+  intent: >
+    Provide independent audit fabric for collecting, retaining, searching, and
+    proving integrity of audit events.
+  includes:
+    - audit ingestion
+    - retention policy
+    - search and export
+    - tamper evidence
+  excludes:
+    - generating domain business events
+    - procuring or operating platform backup
+    - booked financial facts
+  use_cases: []
+
+availability:
+  current_level: A4
+  target_level: A5
+  current_artifacts:
+    - audit-core/deploy/audit-core.yaml
+    - audit-core/audit_core/postgres_backend.py
+    - rapp-postgres/consumers/audit-core.yaml
+  consumption_modes:
+    - http ingest
+    - source module
+
+relations:
+  depends_on: []
+  related_to:
+    - capability.activity.event-coordinate
+    - capability.statehub.progress-log
+  uses_provisions:
+    - data.transactional (rapp-postgres/platform-pg)
+    - data.backup (resource:platform:audit-storage, cited)
+    - security.secrets (OpenBao / ESO)
+
+consumer_guidance:
+  recommended_for:
+    - platform and application audit event delivery over POST /v1/events
+  not_recommended_for:
+    - treating this store as WORM archive
+    - replacing application-level logging only
+  known_limitations:
+    - recoverable history is the 30-day platform backup window
+    - no hash-chain or export API yet
+---
+
+# Audit Event Retention
+
+Audit Core provides the operational custody layer for audit events.
+ITC-CAP join: `operations.audit` at provision maturity D4
+(`data/capability/audit-core-operational.json`). Maturity is not a
+property of this abstract capability.
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/audit-core/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/audit-core/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..573e997
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/audit-core/registry/indexes/capabilities.yaml
@@ -0,0 +1,22 @@
+version: 1
+updated: '2026-08-16'
+domain: infotech
+capabilities:
+- id: capability.audit.event-retain
+  name: Audit Event Retention
+  summary: Collect, normalize, retain, and search audit events with integrity evidence
+    across tenants.
+  joins: operations.audit
+  provision: data/capability/audit-core-operational.json
+  vector: D4 provision / A4 / C3 / R2
+  domain: infotech
+  status: production
+  owner: audit-core
+  path: registry/capabilities/capability.audit.event-retain.md
+  tags:
+  - audit
+  - retention
+  - compliance
+  consumption_modes:
+  - http ingest
+  - source module
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/coordination-engine/registry/NO_CAPABILITIES.md b/docs/assessments/netkingdom-2026-10-14/registry-before/coordination-engine/registry/NO_CAPABILITIES.md
new file mode 100644
index 0000000..a626ddb
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/coordination-engine/registry/NO_CAPABILITIES.md
@@ -0,0 +1,15 @@
+---
+repo: coordination-engine
+reason: >
+  Ambitious coordination-framework prose in INTENT, but only history/spec/registry dirs exist — no runtime code yet.
+reviewed: "2026-07-06"
+reviewed_by: claude-code
+revisit: >
+  Revisit once runtime code for the coordination framework lands.
+---
+
+# No reusable capability
+
+This repo was reviewed for the `reuse-surface` capability registry
+(REUSE-WP-0017 coverage campaign) and has no capability to register at this
+time. See the `reason` field above.
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/coordination-engine/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/coordination-engine/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..f944e47
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/coordination-engine/registry/indexes/capabilities.yaml
@@ -0,0 +1,4 @@
+version: 1
+updated: '2026-06-16'
+domain: helix_forge
+capabilities: []
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/glas-harness/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/glas-harness/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..f944e47
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/glas-harness/registry/indexes/capabilities.yaml
@@ -0,0 +1,4 @@
+version: 1
+updated: '2026-06-16'
+domain: helix_forge
+capabilities: []
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/info-tech-canon/registry/capabilities/capability.infotech.canon-service.md b/docs/assessments/netkingdom-2026-10-14/registry-before/info-tech-canon/registry/capabilities/capability.infotech.canon-service.md
new file mode 100644
index 0000000..2c22dda
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/info-tech-canon/registry/capabilities/capability.infotech.canon-service.md
@@ -0,0 +1,120 @@
+---
+id: capability.infotech.canon-service
+name: InfoTechCanon Service Surface
+summary: Concrete service surface (CLI, importable functions, read-only local HTTP API) over the InfoTechCanon
+  information-processing infospace, backed by infospace-bench.
+owner: info-tech-canon
+status: draft
+domain: infotech
+tags:
+- canon
+- infospace
+- service
+maturity:
+  discovery:
+    current: D2
+    target: D4
+    confidence: medium
+    rationale: README documents a working CLI surface (inspect, artifacts, models, standards, review-kit,
+      alignment-template, validate, graph) over one concrete infospace under infospace/.
+  availability:
+    current: A2
+    target: A3
+    confidence: medium
+    rationale: Runnable today via `PYTHONPATH=src python3 -m info_tech_canon ...`; includes a read-only
+      local HTTP API in addition to the CLI.
+external_evidence:
+  completeness:
+    level: C1
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - CLI commands for inspect/artifacts/models/standards/review-kit/alignment-template/validate/graph
+    - read-only local HTTP API
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R0
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - depends on infospace-bench for artifact loading/checks/graph summaries; only one concrete infospace
+      implemented so far
+discovery:
+  intent: Provide a small, concrete service surface over one InfoTechCanon infospace so the canon corpus
+    is usable via CLI, importable functions, or a read-only API, not just documentation.
+  includes:
+  - JSON-first CLI over the infospace
+  - importable Python service functions
+  - read-only local HTTP API
+  excludes:
+  - the underlying infospace-bench workspace/evaluation tooling itself (separate capability)
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A2
+  target_level: A3
+  current_artifacts:
+  - Python package (`info_tech_canon`)
+  target_artifacts: []
+  consumption_modes:
+  - cli
+  - library import
+  - http api (read-only, local)
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+evidence:
+  documentation:
+  - README.md
+  tests:
+  - tests/
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - consumers wanting programmatic or CLI access to the InfoTechCanon infospace
+  not_recommended_for:
+  - needs requiring a writable or hosted API
+  known_limitations:
+  - only one concrete infospace implemented under infospace/ so far
+promotion_history: []
+---
+
+# InfoTechCanon Service Surface
+
+## Overview
+
+`info-tech-canon` implements a concrete service surface over one InfoTechCanon infospace: a JSON-first CLI, importable Python functions, and a read-only local HTTP API, backed by artifact loading and graph summaries from `infospace-bench`.
+
+## Assessment notes
+
+### Discovery
+
+README documents a working CLI surface (inspect, artifacts, models, standards, review-kit, alignment-template, validate, graph) over one concrete infospace under infospace/.
+
+### Availability
+
+Runnable today via `PYTHONPATH=src python3 -m info_tech_canon ...`; includes a read-only local HTTP API in addition to the CLI.
+
+### Completeness
+
+First-pass honest assessment from the REUSE-WP-0017 coverage campaign
+(reuse-surface). No external consumer feedback exists yet; levels reflect
+scope-vs-intent documentation quality, not internal code quality.
+
+### Reliability
+
+No production consumer telemetry exists yet; reliability level is
+intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [ ] Relations reference valid capability IDs (none yet)
+- [x] Index entry added in `registry/indexes/capabilities.yaml`
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/info-tech-canon/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/info-tech-canon/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..9d37b0d
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/info-tech-canon/registry/indexes/capabilities.yaml
@@ -0,0 +1,21 @@
+version: 1
+updated: '2026-07-06'
+domain: helix_forge
+capabilities:
+- id: capability.infotech.canon-service
+  name: InfoTechCanon Service Surface
+  summary: Concrete service surface (CLI, importable functions, read-only local HTTP API) over the InfoTechCanon
+    information-processing infospace, backed by infospace-bench.
+  vector: D2 / A2 / C1 / R0
+  domain: infotech
+  status: draft
+  owner: info-tech-canon
+  path: registry/capabilities/capability.infotech.canon-service.md
+  tags:
+  - canon
+  - infospace
+  - service
+  consumption_modes:
+  - cli
+  - library import
+  - http api (read-only, local)
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/issue-core/registry/capabilities/capability.infotech.issue-tracking.md b/docs/assessments/netkingdom-2026-10-14/registry-before/issue-core/registry/capabilities/capability.infotech.issue-tracking.md
new file mode 100644
index 0000000..1efc9e5
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/issue-core/registry/capabilities/capability.infotech.issue-tracking.md
@@ -0,0 +1,85 @@
+---
+id: capability.infotech.issue-tracking
+name: External Issue Tracker Connector
+summary: Backend-agnostic CLI/Python connector to Forgejo (and SQLite cache)
+  with work-record UUID ↔ external issue mapping. Not the fleet work origin.
+owner: issue-core
+status: draft
+domain: infotech
+tags:
+- issue-tracking
+- connector
+- work-record
+maturity:
+  discovery:
+    current: D4
+    target: D5
+    confidence: high
+    rationale: INTENT.md, SCOPE.md, CAPABILITY-issue-tracking.yaml, mapping design,
+      boundary-sync policy, AGENT_INTEGRATION.md.
+  availability:
+    current: A2
+    target: A3
+    confidence: high
+    rationale: Python package + CLI (list/create/project/map) installable via pip;
+      mapping store shipped; MCP not yet available.
+external_evidence:
+  completeness:
+    level: C2
+    confidence: medium
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - Forgejo + local SQLite backends
+    - CLI with JSON output; project/map commands
+    - work_record_uuid optional on TaskSpec
+    - credential handling via env vars (FORGEJO_TOKEN preferred; GITEA_API_TOKEN deprecated alias; ISSUE_CORE_API_KEY)
+    broken_expectations: []
+    out_of_scope_expectations:
+    - Fleet task origin / intake promotion (work-record canon)
+    - Default IssueSink for internal findings (activity-core)
+  reliability:
+    level: R1
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - manual backend configuration (auto-detect planned)
+    - no built-in issue locking beyond assignee+state
+    - inward boundary sync not shipped
+discovery:
+  intent: Project and operate on external issue trackers with a stable link to
+    work-record UUIDs; never replace file-first work records as coordination substrate.
+  includes:
+  - unified Python API and CLI over Forgejo/SQLite issue operations
+  - work_record_issue_map store + project/map/push-status
+  - local offline cache and backend sync
+  - credential handling via environment variables
+  excludes:
+  - originating workplans/tasks/intake
+  - MCP server (planned)
+  - multi-agent fleet board semantics on Forgejo
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A2
+  target_level: A3
+  current_artifacts:
+  - Python package (`issue_core`)
+  - '`issue` CLI (including project/map)'
+  target_artifacts: []
+  consumption_modes:
+  - cli
+  - library import
+  - rest (optional `[api]` extra)
+relations:
+  depends_on: []
+  supports: []
+  related_to:
+  - capability.activity.event-coordinate
+evidence:
+  documentation:
+  - INTENT.md
+  - SCOPE.md
+  - CAPABILITY-issue-tracking.yaml
+  - docs/uuid-external-id-mapping.md
+  - docs/boundary-sync-and-status-mapping.md
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/issue-core/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/issue-core/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..7be3fce
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/issue-core/registry/indexes/capabilities.yaml
@@ -0,0 +1,20 @@
+version: 1
+updated: '2026-07-07'
+domain: helix_forge
+capabilities:
+- id: capability.infotech.issue-tracking
+  name: Universal Issue Tracking Coordination
+  summary: Unified Python/CLI interface for issue tracking across Forgejo, GitHub, and GitLab, preventing
+    direct platform API usage and credential sprawl for coordinating agents.
+  vector: D4 / A2 / C2 / R1
+  domain: infotech
+  status: draft
+  owner: issue-core
+  path: registry/capabilities/capability.infotech.issue-tracking.md
+  tags:
+  - issue-tracking
+  - coordination
+  - multi-platform
+  consumption_modes:
+  - cli
+  - library import
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/key-cape/registry/capabilities/capability.iam.key-cape.md b/docs/assessments/netkingdom-2026-10-14/registry-before/key-cape/registry/capabilities/capability.iam.key-cape.md
new file mode 100644
index 0000000..0c096ec
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/key-cape/registry/capabilities/capability.iam.key-cape.md
@@ -0,0 +1,125 @@
+---
+id: capability.iam.key-cape
+name: KeyCape Lightweight IAM (NetKingdom Profile)
+summary: Lightweight-mode implementation of the NetKingdom IAM Profile (versioned OIDC/PKCE contract),
+  orchestrating Authelia, LLDAP, and privacyIDEA so applications integrate against the profile, not against
+  implementation internals.
+owner: key-cape
+status: draft
+domain: infotech
+tags:
+- iam
+- oidc
+- netkingdom
+- security
+maturity:
+  discovery:
+    current: D4
+    target: D5
+    confidence: high
+    rationale: README documents a versioned canonical contract (net-kingdom canon/standards/iam-profile_v0.2.md),
+      explicit lightweight-vs-expanded (Keycloak) migration story, and a completed implementation status
+      (all 23 workplan tasks, 21 green test packages).
+  availability:
+    current: A2
+    target: A3
+    confidence: high
+    rationale: README states 'Implementation complete (v0.1)'; has both `.gitea/workflows/` and `.forgejo/workflows/`
+      CI already in place — ahead of most siblings on the Forgejo transition.
+external_evidence:
+  completeness:
+    level: C2
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - full v0.1 implementation per its own workplan (23/23 tasks)
+    - 21 test packages, all green
+    - documented lightweight-to-expanded (Keycloak) migration path
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R1
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - maturity claims rely on the repo's own workplan completion record, not independently re-verified
+      in this sweep
+discovery:
+  intent: Let applications integrate against a versioned IAM profile contract rather than against Keycape
+    internals, so migrating from lightweight (Authelia/LLDAP/privacyIDEA) to expanded (Keycloak) mode
+    is a tested operation, not a rewrite.
+  includes:
+  - NetKingdom IAM Profile v0.2 lightweight-mode orchestration (Authelia, LLDAP, privacyIDEA)
+  - profile-contract conformance
+  excludes:
+  - expanded-mode (Keycloak) implementation itself (separate deployment target for the same profile)
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A2
+  target_level: A3
+  current_artifacts:
+  - deployable lightweight-mode IAM stack
+  target_artifacts: []
+  consumption_modes:
+  - service (self-hosted deployment)
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+evidence:
+  documentation:
+  - README.md
+  - workplans/KEY-WP-0001-keycape-implementation.md
+  tests:
+  - .gitea/workflows/
+  - .forgejo/workflows/
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - NetKingdom deployments wanting a lightweight, self-hosted IAM profile implementation with a tested
+    migration path to Keycloak
+  not_recommended_for:
+  - deployments already committed to expanded/Keycloak mode
+  known_limitations:
+  - v0.1 completion claim not independently re-verified during this coverage sweep
+promotion_history: []
+---
+
+# KeyCape Lightweight IAM (NetKingdom Profile)
+
+## Overview
+
+KeyCape is the lightweight IAM component of NetKingdom, implementing the versioned NetKingdom IAM Profile (OIDC/PKCE) by orchestrating Authelia, LLDAP, and privacyIDEA — the same profile Keycloak implements in expanded-mode deployments, so migration is a tested operation rather than a rewrite.
+
+## Assessment notes
+
+### Discovery
+
+README documents a versioned canonical contract (net-kingdom canon/standards/iam-profile_v0.2.md), explicit lightweight-vs-expanded (Keycloak) migration story, and a completed implementation status (all 23 workplan tasks, 21 green test packages).
+
+### Availability
+
+README states 'Implementation complete (v0.1)'; has both `.gitea/workflows/` and `.forgejo/workflows/` CI already in place — ahead of most siblings on the Forgejo transition.
+
+### Completeness
+
+First-pass honest assessment from the REUSE-WP-0017 coverage campaign
+(reuse-surface). No external consumer feedback exists yet; levels reflect
+scope-vs-intent documentation quality, not internal code quality.
+
+### Reliability
+
+No production consumer telemetry exists yet; reliability level is
+intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [ ] Relations reference valid capability IDs (none yet)
+- [x] Index entry added in `registry/indexes/capabilities.yaml`
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/key-cape/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/key-cape/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..af664bf
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/key-cape/registry/indexes/capabilities.yaml
@@ -0,0 +1,21 @@
+version: 1
+updated: '2026-07-06'
+domain: helix_forge
+capabilities:
+- id: capability.iam.key-cape
+  name: KeyCape Lightweight IAM (NetKingdom Profile)
+  summary: Lightweight-mode implementation of the NetKingdom IAM Profile (versioned OIDC/PKCE contract),
+    orchestrating Authelia, LLDAP, and privacyIDEA so applications integrate against the profile, not
+    against implementation internals.
+  vector: D4 / A2 / C2 / R1
+  domain: infotech
+  status: draft
+  owner: key-cape
+  path: registry/capabilities/capability.iam.key-cape.md
+  tags:
+  - iam
+  - oidc
+  - netkingdom
+  - security
+  consumption_modes:
+  - service (self-hosted deployment)
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/net-kingdom/registry/capabilities/capability.security.iam-tooling-suite.md b/docs/assessments/netkingdom-2026-10-14/registry-before/net-kingdom/registry/capabilities/capability.security.iam-tooling-suite.md
new file mode 100644
index 0000000..2064c96
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/net-kingdom/registry/capabilities/capability.security.iam-tooling-suite.md
@@ -0,0 +1,148 @@
+---
+id: capability.security.iam-tooling-suite
+name: NetKingdom Security/IAM Tooling Suite
+summary: Canonical security architecture and executable reference tooling for IAM, bootstrap, posture validation,
+  deterministic plan-only security scenario composition, and proposal-only posture feedback.
+owner: net-kingdom
+status: draft
+domain: infotech
+tags:
+- security
+- iam
+- kubernetes
+- conformance
+maturity:
+  discovery:
+    current: D3
+    target: D5
+    confidence: medium
+    rationale: SCOPE plus docs/secrets-engine-security-infrastructure-boundary.md describe an explicit
+      integration boundary with OpenBao, flex-auth, user-engine, ops-warden, ops-bridge, info-tech-canon,
+      and State Hub; canon/standards/ holds versioned IAM v0.3, playbook capability, scenario composition,
+      tenancy, zone, and boundary standards that provider repos implement against.
+  availability:
+    current: A2
+    target: A3
+    confidence: medium
+    rationale: 'No top-level package manifest, but tools/ holds independently documented and runnable
+      conformance, posture, posture-feedback, scenario-composition, and guarded bootstrap tools; local-identity is separately
+      packaged and tested.'
+external_evidence:
+  completeness:
+    level: C1
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - versioned canon standards already implemented by a sibling repo (key-cape)
+    - documented, runnable conformance, posture, composition, and bootstrap tools under tools/
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R1
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - no top-level packaging; each tool under tools/ has its own runtime dependencies, no unified install
+      path yet
+discovery:
+  intent: Own canonical NetKingdom security semantics and provide executable reference and conformance tooling
+    so provider implementations can integrate without inferred authority or hidden deployment coupling.
+  includes:
+  - canon/standards/ versioned IAM, tenancy, zone, credential, boundary, and composition standards
+  - IAM profile conformance checker
+  - playbook capability contract validator
+  - deterministic plan-only security scenario composer
+  - tenancy posture schema and validator
+  - deterministic proposal-only posture feedback evaluator
+  - security bootstrap console (local, non-secret-collecting)
+  - packaged local bootstrap identity CLI
+  excludes:
+  - concrete IAM implementations themselves (see key-cape for lightweight mode)
+  - live secret value handling (bootstrap console explicitly refuses live OpenBao initialization)
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A2
+  target_level: A3
+  current_artifacts:
+  - tools/iam-profile-conformance
+  - tools/playbook-capability-contract
+  - tools/security-scenario-composer
+  - tools/tenancy-posture
+  - tools/posture-feedback
+  - tools/security-bootstrap-console
+  - local-identity
+  target_artifacts: []
+  consumption_modes:
+  - cli
+  - local web ui
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+evidence:
+  documentation:
+  - README.md
+  - docs/secrets-engine-security-infrastructure-boundary.md
+  - tools/*/README.md
+  tests:
+  - tools/iam-profile-conformance (pytest fixtures)
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - implementers needing to verify IAM/security conformance against Coulomb's canonical standards
+  not_recommended_for:
+  - needs for a packaged, single-install security suite (currently three separate tools)
+  known_limitations:
+  - no unified top-level packaging across the three tools
+promotion_history: []
+---
+
+# NetKingdom Security/IAM Tooling Suite
+
+## Overview
+
+`net-kingdom` provides canonical IAM and security architecture, executable
+conformance and posture checks, deterministic plan-only scenario composition,
+proposal-only posture feedback, a local bootstrap identity package, and a non-secret-collecting security
+bootstrap console. Provider implementations remain in sibling repositories such
+as `key-cape`; the self-optimizing platform remains an intent rather than a
+current delivery claim.
+
+## Assessment notes
+
+### Discovery
+
+SCOPE plus docs/secrets-engine-security-infrastructure-boundary.md describe an
+explicit integration boundary with OpenBao, flex-auth, user-engine, ops-warden,
+ops-bridge, info-tech-canon, and State Hub. `canon/standards/` holds the current
+IAM v0.3 and related boundary, posture, zone, credential, playbook, and scenario
+composition standards.
+
+### Availability
+
+No top-level package manifest exists. The independently runnable surfaces are
+documented under `tools/`, and `local-identity` has its own package manifest and
+test environment.
+
+### Completeness
+
+First-pass honest assessment from the REUSE-WP-0017 coverage campaign
+(reuse-surface). No external consumer feedback exists yet; levels reflect
+scope-vs-intent documentation quality, not internal code quality.
+
+### Reliability
+
+No production consumer telemetry exists yet; reliability level is
+intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [ ] Relations reference valid capability IDs (none yet)
+- [x] Index entry added in `registry/indexes/capabilities.yaml`
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/net-kingdom/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/net-kingdom/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..3a618f7
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/net-kingdom/registry/indexes/capabilities.yaml
@@ -0,0 +1,21 @@
+version: 1
+updated: '2026-08-23'
+domain: helix_forge
+capabilities:
+- id: capability.security.iam-tooling-suite
+  name: NetKingdom Security/IAM Tooling Suite
+  summary: Canonical security architecture and executable reference tooling for IAM, bootstrap, posture
+    validation, deterministic plan-only security scenario composition, and proposal-only posture feedback.
+  vector: D3 / A2 / C1 / R1
+  domain: infotech
+  status: draft
+  owner: net-kingdom
+  path: registry/capabilities/capability.security.iam-tooling-suite.md
+  tags:
+  - security
+  - iam
+  - kubernetes
+  - conformance
+  consumption_modes:
+  - cli
+  - local web ui
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/ops-bridge/registry/capabilities/capability.ops.tunnel-bridge.md b/docs/assessments/netkingdom-2026-10-14/registry-before/ops-bridge/registry/capabilities/capability.ops.tunnel-bridge.md
new file mode 100644
index 0000000..19f0a29
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/ops-bridge/registry/capabilities/capability.ops.tunnel-bridge.md
@@ -0,0 +1,122 @@
+---
+id: capability.ops.tunnel-bridge
+name: SSH Reverse Tunnel Lifecycle Manager (ops-bridge)
+summary: CLI that manages named SSH reverse tunnels keeping remote execution environments connected to
+  the local Custodian State Hub, with auto-reconnect, health checks, and structured audit events.
+owner: ops-bridge
+status: draft
+domain: infotech
+tags:
+- ssh
+- tunnel
+- ops
+- connectivity
+maturity:
+  discovery:
+    current: D3
+    target: D5
+    confidence: medium
+    rationale: README.txt documents named tunnels, auto-reconnect with exponential backoff, HTTP health
+      checks, and structured JSON audit events per tunnel; this is also the tool underlying reuse-surface's
+      own `/bridge` skill.
+  availability:
+    current: A2
+    target: A3
+    confidence: medium
+    rationale: Ships a `bridge` CLI, installable via pyproject; already actively used to keep remote Claude
+      Code sessions (COULOMBCORE, Railiance nodes) connected to the State Hub MCP.
+external_evidence:
+  completeness:
+    level: C2
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - auto-reconnecting named SSH reverse tunnels
+    - HTTP health checks confirming forwarded service reachability, not just SSH liveness
+    - structured audit event log per tunnel
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R1
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - operational tool with real production usage but no independent load/failure testing recorded in
+      this sweep
+discovery:
+  intent: Keep remote execution environments' MCP connectivity to the local State Hub alive and observable
+    via managed, auto-reconnecting SSH reverse tunnels.
+  includes:
+  - named SSH reverse tunnel lifecycle management
+  - auto-reconnect with exponential backoff
+  - HTTP health checks
+  - structured audit event logging
+  excludes:
+  - the State Hub or MCP servers themselves (bridge only manages connectivity)
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A2
+  target_level: A3
+  current_artifacts:
+  - '`bridge` CLI'
+  target_artifacts: []
+  consumption_modes:
+  - cli
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+evidence:
+  documentation:
+  - README.txt
+  tests:
+  - tests/
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - any workstation/remote-machine pair needing durable SSH-tunneled MCP or service connectivity
+  not_recommended_for:
+  - needs for tunnel types other than SSH reverse port-forwards
+  known_limitations:
+  - no independent load/failure testing recorded beyond production usage observations
+promotion_history: []
+---
+
+# SSH Reverse Tunnel Lifecycle Manager (ops-bridge)
+
+## Overview
+
+`ops-bridge` is an SSH reverse tunnel lifecycle manager: a `bridge` CLI that keeps remote execution environments (COULOMBCORE, Railiance nodes) connected to the local Custodian State Hub, with auto-reconnect, health checks, and structured audit logging per tunnel.
+
+## Assessment notes
+
+### Discovery
+
+README.txt documents named tunnels, auto-reconnect with exponential backoff, HTTP health checks, and structured JSON audit events per tunnel; this is also the tool underlying reuse-surface's own `/bridge` skill.
+
+### Availability
+
+Ships a `bridge` CLI, installable via pyproject; already actively used to keep remote Claude Code sessions (COULOMBCORE, Railiance nodes) connected to the State Hub MCP.
+
+### Completeness
+
+First-pass honest assessment from the REUSE-WP-0017 coverage campaign
+(reuse-surface). No external consumer feedback exists yet; levels reflect
+scope-vs-intent documentation quality, not internal code quality.
+
+### Reliability
+
+No production consumer telemetry exists yet; reliability level is
+intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [ ] Relations reference valid capability IDs (none yet)
+- [x] Index entry added in `registry/indexes/capabilities.yaml`
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/ops-bridge/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/ops-bridge/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..a67521a
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/ops-bridge/registry/indexes/capabilities.yaml
@@ -0,0 +1,20 @@
+version: 1
+updated: '2026-07-06'
+domain: helix_forge
+capabilities:
+- id: capability.ops.tunnel-bridge
+  name: SSH Reverse Tunnel Lifecycle Manager (ops-bridge)
+  summary: CLI that manages named SSH reverse tunnels keeping remote execution environments connected
+    to the local Custodian State Hub, with auto-reconnect, health checks, and structured audit events.
+  vector: D3 / A2 / C2 / R1
+  domain: infotech
+  status: draft
+  owner: ops-bridge
+  path: registry/capabilities/capability.ops.tunnel-bridge.md
+  tags:
+  - ssh
+  - tunnel
+  - ops
+  - connectivity
+  consumption_modes:
+  - cli
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/ops-warden/registry/capabilities/capability.security.ssh-certificate-issuance.md b/docs/assessments/netkingdom-2026-10-14/registry-before/ops-warden/registry/capabilities/capability.security.ssh-certificate-issuance.md
new file mode 100644
index 0000000..d62d348
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/ops-warden/registry/capabilities/capability.security.ssh-certificate-issuance.md
@@ -0,0 +1,137 @@
+---
+id: capability.security.ssh-certificate-issuance
+name: SSH Certificate Issuance
+summary: Issue short-lived CA-signed SSH certificates for adm, agt, and atm actors through a stable cert_command CLI interface; steward operational access routing across NetKingdom security lanes.
+owner: ops-warden
+status: draft
+domain: helix_forge
+tags:
+  - ssh
+  - certificate
+  - ca
+  - ops-warden
+  - openbao
+  - security
+
+maturity:
+  discovery:
+    current: D4
+    target: D5
+    confidence: medium
+    rationale: >
+      SCOPE, AccessManagementDirective alignment, config runbooks, and cert_command
+      contract are documented; production OpenBao integration is documented but
+      engine deployment lives in railiance-platform. A machine-readable routing
+      catalog (registry/routing/catalog.yaml) and wiki/AccessRouting.md make the
+      "issue SSH, route the rest" boundary discoverable.
+  availability:
+    current: A3
+    target: A5
+    confidence: medium
+    rationale: >
+      Installable `warden` CLI and `ops-ssh-wrapper` entry points; ops-bridge and
+      other callers integrate via cert_command without backend-specific branching.
+      A `warden route` lookup over the pointer catalog (WARDEN-WP-0011) will move
+      routing discovery from wiki prose to a structured surface for agents (A3 -> A4).
+
+external_evidence:
+  completeness:
+    level: C3
+    name: Functional Core
+    confidence: medium
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+      - local and OpenBao/Vault-compatible signing backends
+      - TTL policy enforcement per actor type
+      - principals inventory and cert-side scorecard
+      - signatures audit log and stale-cert cleanup
+      - cert_command stdout contract for ops-bridge
+    broken_expectations:
+      - host-side principal deployment not owned here
+      - OpenBao SSH engine mount not deployed from this repo
+    out_of_scope_expectations:
+      - long-lived API key custody
+      - tunnel lifecycle management
+      - Vault/OpenBao cluster operations
+  reliability:
+    level: R2
+    name: Tolerable
+    confidence: medium
+    basis: consumer_quality_signals
+    known_reliability_risks:
+      - production signing depends on OpenBao availability and token policy
+      - local backend requires protected CA key handling by operators
+
+discovery:
+  intent: >
+    Give the ops fleet short-lived SSH credentials for humans, agents, and
+    automations without static keys, through a single cert_command surface that
+    callers can rely on regardless of CA backend; route non-SSH credential needs
+    to the correct NetKingdom subsystems (OpenBao, flex-auth, key-cape).
+  includes:
+    - certificate signing for adm, agt, and atm actors
+    - actor principals inventory and TTL policy
+    - cert_command interface (`warden sign`)
+    - cert-side compliance scorecard and signatures log
+    - ops-ssh-wrapper for automatic cert acquisition
+    - NetKingdom credential routing and alignment documentation
+    - machine-readable routing pointer catalog (registry/routing/catalog.yaml)
+  excludes:
+    - tunnel lifecycle
+    - host /etc/ssh/auth_principals deployment
+    - OpenBao or Vault cluster setup
+    - long-lived secret storage
+  assumptions:
+    - callers supply actor public keys; humans self-issue admin keys
+    - production platform uses OpenBao with Vault-compatible SSH engine API
+  use_cases:
+    - ops-bridge tunnel cert_command
+    - Inter-Hub bootstrap short-lived agent access
+  research_memos:
+    - ops-warden/SCOPE.md
+    - ops-warden/wiki/CertCommandInterface.md
+    - ops-warden/wiki/OpsWardenConfig.md
+    - ops-warden/wiki/AccessRouting.md
+
+availability:
+  current_level: A3
+  target_level: A5
+  current_artifacts:
+    - ops-warden/src/warden/
+    - ops-warden/wiki/CertCommandInterface.md
+    - ops-warden/wiki/OpsWardenConfig.md
+  target_artifacts:
+    - packaged ops-warden release with documented OpenBao role bootstrap
+    - "`warden route` lookup CLI over the pointer catalog (WARDEN-WP-0011)"
+  consumption_modes:
+    - CLI
+    - cert_command subprocess
+
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+
+consumer_guidance:
+  recommended_for:
+    - issuing short-lived SSH certs for ops-bridge tunnels
+    - agent or automation access with TTL-bound principals
+    - checking cert-side compliance before rotation windows
+    - orienting dev workers on which NetKingdom subsystem owns each credential type
+  not_recommended_for:
+    - storing OpenRouter or Inter-Hub API keys
+    - replacing OpenBao deployment or host SSH hardening playbooks
+    - static-key-only legacy access (use ops-bridge static key mode instead)
+  known_limitations:
+    - "VaultCA backend config key remains backend: vault for API compatibility"
+    - host-side scorecard checks live in railiance-infra
+---
+
+# SSH Certificate Issuance
+
+ops-warden is the custodian-domain SSH CA tool. It signs short-lived certificates,
+maintains the actor inventory, and exposes `warden sign` as the cert_command
+contract for ops-bridge and other callers.
+
+Production environments point the vault-compatible backend at OpenBao; labs use
+the local ssh-keygen CA backend without platform dependencies.
\ No newline at end of file
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/ops-warden/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/ops-warden/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..218a9ab
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/ops-warden/registry/indexes/capabilities.yaml
@@ -0,0 +1,23 @@
+version: 1
+updated: '2026-06-17'
+domain: helix_forge
+capabilities:
+- id: capability.security.ssh-certificate-issuance
+  name: SSH Certificate Issuance
+  summary: Issue short-lived CA-signed SSH certificates for adm, agt, and atm actors
+    through a stable cert_command CLI interface; steward NetKingdom operational access routing.
+  vector: D4 / A3 / C3 / R2
+  domain: helix_forge
+  status: draft
+  owner: ops-warden
+  path: registry/capabilities/capability.security.ssh-certificate-issuance.md
+  tags:
+  - ssh
+  - certificate
+  - ca
+  - ops-warden
+  - openbao
+  - security
+  consumption_modes:
+  - CLI
+  - cert_command subprocess
\ No newline at end of file
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-apps/registry/capabilities/capability.railiance.workload-deployment-tooling.md b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-apps/registry/capabilities/capability.railiance.workload-deployment-tooling.md
new file mode 100644
index 0000000..4e64f96
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-apps/registry/capabilities/capability.railiance.workload-deployment-tooling.md
@@ -0,0 +1,127 @@
+---
+id: capability.railiance.workload-deployment-tooling
+name: Railiance Application Workload Deployment Tooling
+summary: S5 Workloads and Experience Endpoints layer of the Railiance OAS Stack — application Helm releases,
+  Kubernetes workload manifests, deployment guardrails, and smoke-test/check tooling for user-facing services.
+owner: railiance-apps
+status: draft
+domain: financials
+tags:
+- railiance
+- kubernetes
+- helm
+- deployment
+maturity:
+  discovery:
+    current: D3
+    target: D4
+    confidence: medium
+    rationale: SCOPE.md places this repo precisely in the Railiance OAS Stack layering (S5), scoped to
+      application Helm releases, workload manifests, and operator runbooks for user-facing services such
+      as vergabe-teilnahme.
+  availability:
+    current: A2
+    target: A3
+    confidence: medium
+    rationale: No top-level package manifest, but ships real, runnable tooling under tools/ (build-database-url-secret.sh,
+      check-oci-image.sh, check-sops.sh, forgejo-smoke.sh, inter-hub-smoke.sh, k8s-server-dry-run.sh,
+      smoke-service.sh) plus charts/ and manifests/; has both .gitea and .forgejo CI already.
+external_evidence:
+  completeness:
+    level: C1
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - Helm charts and Kubernetes manifests for application workloads
+    - smoke-test and dry-run check scripts, including a forgejo-smoke.sh already ahead of the platform-wide
+      Forgejo transition
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R1
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - no top-level packaging; tooling is a collection of shell scripts under tools/
+discovery:
+  intent: 'Own the S5 layer of the Railiance OAS Stack: deploying and verifying user-facing application
+    workloads via Helm/Kubernetes with guardrails and operator runbooks.'
+  includes:
+  - application Helm releases and Kubernetes workload manifests
+  - deployment guardrails
+  - smoke-test and dry-run tooling (including forgejo-smoke.sh)
+  excludes:
+  - cluster/platform substrate (see railiance-cluster, railiance-platform)
+  - CI/CD enablement templates (see railiance-enablement)
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A2
+  target_level: A3
+  current_artifacts:
+  - Helm charts
+  - Kubernetes manifests
+  - tools/*.sh smoke and check scripts
+  target_artifacts: []
+  consumption_modes:
+  - cli (shell scripts)
+  - helm/kubernetes deployment
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+evidence:
+  documentation:
+  - SCOPE.md
+  tests:
+  - tools/forgejo-smoke.sh
+  - tools/inter-hub-smoke.sh
+  - tools/k8s-server-dry-run.sh
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - operators deploying or verifying Railiance user-facing application workloads
+  not_recommended_for:
+  - needs at the cluster/platform substrate layer (see railiance-cluster, railiance-platform)
+  known_limitations:
+  - no unified packaging; tooling is a set of independent shell scripts
+promotion_history: []
+---
+
+# Railiance Application Workload Deployment Tooling
+
+## Overview
+
+`railiance-apps` is the S5 Workloads and Experience Endpoints layer of the Railiance OAS Stack: Helm releases, Kubernetes workload manifests, deployment guardrails, and operator runbooks for user-facing services such as `vergabe-teilnahme`, including a `forgejo-smoke.sh` check already ahead of the platform-wide Gitea-to-Forgejo transition.
+
+## Assessment notes
+
+### Discovery
+
+SCOPE.md places this repo precisely in the Railiance OAS Stack layering (S5), scoped to application Helm releases, workload manifests, and operator runbooks for user-facing services such as vergabe-teilnahme.
+
+### Availability
+
+No top-level package manifest, but ships real, runnable tooling under tools/ (build-database-url-secret.sh, check-oci-image.sh, check-sops.sh, forgejo-smoke.sh, inter-hub-smoke.sh, k8s-server-dry-run.sh, smoke-service.sh) plus charts/ and manifests/; has both .gitea and .forgejo CI already.
+
+### Completeness
+
+First-pass honest assessment from the REUSE-WP-0017 coverage campaign
+(reuse-surface). No external consumer feedback exists yet; levels reflect
+scope-vs-intent documentation quality, not internal code quality.
+
+### Reliability
+
+No production consumer telemetry exists yet; reliability level is
+intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [ ] Relations reference valid capability IDs (none yet)
+- [x] Index entry added in `registry/indexes/capabilities.yaml`
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-apps/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-apps/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..38b1f91
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-apps/registry/indexes/capabilities.yaml
@@ -0,0 +1,22 @@
+version: 1
+updated: '2026-07-06'
+domain: helix_forge
+capabilities:
+- id: capability.railiance.workload-deployment-tooling
+  name: Railiance Application Workload Deployment Tooling
+  summary: S5 Workloads and Experience Endpoints layer of the Railiance OAS Stack — application Helm releases,
+    Kubernetes workload manifests, deployment guardrails, and smoke-test/check tooling for user-facing
+    services.
+  vector: D3 / A2 / C1 / R1
+  domain: financials
+  status: draft
+  owner: railiance-apps
+  path: registry/capabilities/capability.railiance.workload-deployment-tooling.md
+  tags:
+  - railiance
+  - kubernetes
+  - helm
+  - deployment
+  consumption_modes:
+  - cli (shell scripts)
+  - helm/kubernetes deployment
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-bootstrap/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-bootstrap/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..f944e47
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-bootstrap/registry/indexes/capabilities.yaml
@@ -0,0 +1,4 @@
+version: 1
+updated: '2026-06-16'
+domain: helix_forge
+capabilities: []
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-cluster/registry/capabilities/capability.railiance.cluster-bootstrap.md b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-cluster/registry/capabilities/capability.railiance.cluster-bootstrap.md
new file mode 100644
index 0000000..b1e3b8a
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-cluster/registry/capabilities/capability.railiance.cluster-bootstrap.md
@@ -0,0 +1,122 @@
+---
+id: capability.railiance.cluster-bootstrap
+name: Railiance Cluster Runtime Bootstrap
+summary: 'Cluster runtime entry point of the Railiance Infrastructure-as-Code framework: from two bare
+  Linux servers, a Git repo, and credentials, rebuilds a fully automated Kubernetes-based environment.'
+owner: railiance-cluster
+status: draft
+domain: financials
+tags:
+- railiance
+- kubernetes
+- iac
+- bootstrap
+maturity:
+  discovery:
+    current: D3
+    target: D4
+    confidence: medium
+    rationale: README documents the 'Rails for Ops' convention-over-configuration philosophy and a concrete
+      quick-start (clone, from two bare servers rebuild a full k8s environment); has .forgejo CI already
+      in place.
+  availability:
+    current: A2
+    target: A3
+    confidence: medium
+    rationale: Real Python package (pyproject, requires-python >=3.11) plus bin/railiance CLI and ansible
+      playbooks (bootstrap/harden), with a documented quick-start path.
+external_evidence:
+  completeness:
+    level: C1
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - documented quick-start from two bare servers to a running Kubernetes environment
+    - bootstrap/harden ansible playbooks
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R0
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - reproducibility claims not independently re-verified (no live bootstrap run during this sweep)
+discovery:
+  intent: 'Provide the cluster runtime entry point for Railiance: reproducible, self-reliant Kubernetes
+    environment bootstrap from bare servers via convention-over-configuration IaC.'
+  includes:
+  - cluster bootstrap CLI and ansible playbooks (bootstrap/harden)
+  - Kubernetes-based environment rebuild path
+  excludes:
+  - application workload deployment (see railiance-apps)
+  - platform services like Postgres/Valkey (see railiance-platform)
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A2
+  target_level: A3
+  current_artifacts:
+  - '`railiance` CLI (bin/railiance)'
+  - ansible playbooks
+  target_artifacts: []
+  consumption_modes:
+  - cli
+  - ansible playbook
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+evidence:
+  documentation:
+  - README.md
+  tests:
+  - tests/
+  - .forgejo/
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - operators bootstrapping a new Railiance Kubernetes cluster from bare servers
+  not_recommended_for:
+  - application-level or platform-service deployment (see railiance-apps, railiance-platform)
+  known_limitations:
+  - reproducibility not independently re-verified via a live bootstrap run in this sweep
+promotion_history: []
+---
+
+# Railiance Cluster Runtime Bootstrap
+
+## Overview
+
+`railiance-cluster` is the cluster runtime entry point of the Railiance Infrastructure-as-Code framework: from two bare Linux servers, a Git repo, and credentials, it rebuilds a fully automated Kubernetes-based environment via convention-over-configuration IaC (Terraform/cloud-init/Ansible-adjacent tooling, `railiance` CLI).
+
+## Assessment notes
+
+### Discovery
+
+README documents the 'Rails for Ops' convention-over-configuration philosophy and a concrete quick-start (clone, from two bare servers rebuild a full k8s environment); has .forgejo CI already in place.
+
+### Availability
+
+Real Python package (pyproject, requires-python >=3.11) plus bin/railiance CLI and ansible playbooks (bootstrap/harden), with a documented quick-start path.
+
+### Completeness
+
+First-pass honest assessment from the REUSE-WP-0017 coverage campaign
+(reuse-surface). No external consumer feedback exists yet; levels reflect
+scope-vs-intent documentation quality, not internal code quality.
+
+### Reliability
+
+No production consumer telemetry exists yet; reliability level is
+intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [ ] Relations reference valid capability IDs (none yet)
+- [x] Index entry added in `registry/indexes/capabilities.yaml`
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-cluster/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-cluster/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..f235a35
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-cluster/registry/indexes/capabilities.yaml
@@ -0,0 +1,21 @@
+version: 1
+updated: '2026-07-06'
+domain: helix_forge
+capabilities:
+- id: capability.railiance.cluster-bootstrap
+  name: Railiance Cluster Runtime Bootstrap
+  summary: 'Cluster runtime entry point of the Railiance Infrastructure-as-Code framework: from two bare
+    Linux servers, a Git repo, and credentials, rebuilds a fully automated Kubernetes-based environment.'
+  vector: D3 / A2 / C1 / R0
+  domain: financials
+  status: draft
+  owner: railiance-cluster
+  path: registry/capabilities/capability.railiance.cluster-bootstrap.md
+  tags:
+  - railiance
+  - kubernetes
+  - iac
+  - bootstrap
+  consumption_modes:
+  - cli
+  - ansible playbook
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-enablement/registry/capabilities/capability.railiance.ci-enablement.md b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-enablement/registry/capabilities/capability.railiance.ci-enablement.md
new file mode 100644
index 0000000..fd762e6
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-enablement/registry/capabilities/capability.railiance.ci-enablement.md
@@ -0,0 +1,125 @@
+---
+id: capability.railiance.ci-enablement
+name: Railiance Developer Enablement And CI/CD Templates
+summary: S4 Developer Enablement layer of the Railiance OAS Stack — reusable CI/CD workflow templates,
+  developer portal paths, platform templates, SDKs, and buildpacks, using forge capabilities without owning
+  forge runtime.
+owner: railiance-enablement
+status: draft
+domain: financials
+tags:
+- railiance
+- ci-cd
+- developer-enablement
+- forgejo
+maturity:
+  discovery:
+    current: D3
+    target: D4
+    confidence: medium
+    rationale: SCOPE.md places this repo precisely at S4 in the Railiance OAS Stack, explicitly scoped
+      to reusable CI/CD templates and enablement tooling while using (not owning) forge capabilities.
+  availability:
+    current: A2
+    target: A3
+    confidence: high
+    rationale: Ships real, reusable Forgejo Actions workflow templates (container-build-push.yaml, container-build-push-multirepo.yaml,
+      ci-smoke.yaml) plus `tools/promote-repo-to-forgejo.sh` — directly relevant tooling for the ecosystem-wide
+      Gitea-to-Forgejo transition (REUSE-WP-0019).
+external_evidence:
+  completeness:
+    level: C2
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - reusable Forgejo Actions CI/CD workflow templates already in production shape
+    - a repo-promotion-to-forgejo script directly usable for the platform-wide forge transition
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R1
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - templates are workflow YAML, not a packaged/versioned artifact; consumption is copy/reference rather
+      than dependency-managed
+discovery:
+  intent: Give Railiance repos reusable CI/CD templates and developer-enablement tooling (including forge-promotion
+    tooling) without each repo owning the forge runtime or runner substrate itself.
+  includes:
+  - reusable Forgejo Actions CI/CD workflow templates
+  - repo-to-forgejo promotion tooling
+  - developer portal/platform template scope (per SCOPE.md)
+  excludes:
+  - forge runtime and runner substrate ownership (see railiance-forge)
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A2
+  target_level: A3
+  current_artifacts:
+  - workflows/container-build-push.yaml
+  - workflows/ci-smoke.yaml
+  - tools/promote-repo-to-forgejo.sh
+  target_artifacts: []
+  consumption_modes:
+  - ci workflow template (copy/reference)
+  - cli (promote-repo-to-forgejo.sh)
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+evidence:
+  documentation:
+  - SCOPE.md
+  tests:
+  - workflows/ci-smoke.yaml
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - Railiance repos needing reusable Forgejo Actions CI/CD templates, or any repo executing a Gitea-to-Forgejo
+    promotion
+  not_recommended_for:
+  - needs for owning forge runtime/runner infrastructure itself (see railiance-forge)
+  known_limitations:
+  - templates are consumed by copy/reference, not as a versioned dependency
+promotion_history: []
+---
+
+# Railiance Developer Enablement And CI/CD Templates
+
+## Overview
+
+`railiance-enablement` is the S4 Developer Enablement layer of the Railiance OAS Stack: reusable CI/CD workflow templates and developer-enablement tooling, including a `promote-repo-to-forgejo.sh` script directly relevant to the ecosystem-wide Gitea-to-Forgejo transition tracked in REUSE-WP-0019.
+
+## Assessment notes
+
+### Discovery
+
+SCOPE.md places this repo precisely at S4 in the Railiance OAS Stack, explicitly scoped to reusable CI/CD templates and enablement tooling while using (not owning) forge capabilities.
+
+### Availability
+
+Ships real, reusable Forgejo Actions workflow templates (container-build-push.yaml, container-build-push-multirepo.yaml, ci-smoke.yaml) plus `tools/promote-repo-to-forgejo.sh` — directly relevant tooling for the ecosystem-wide Gitea-to-Forgejo transition (REUSE-WP-0019).
+
+### Completeness
+
+First-pass honest assessment from the REUSE-WP-0017 coverage campaign
+(reuse-surface). No external consumer feedback exists yet; levels reflect
+scope-vs-intent documentation quality, not internal code quality.
+
+### Reliability
+
+No production consumer telemetry exists yet; reliability level is
+intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [ ] Relations reference valid capability IDs (none yet)
+- [x] Index entry added in `registry/indexes/capabilities.yaml`
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-enablement/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-enablement/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..6fdd537
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-enablement/registry/indexes/capabilities.yaml
@@ -0,0 +1,22 @@
+version: 1
+updated: '2026-07-06'
+domain: helix_forge
+capabilities:
+- id: capability.railiance.ci-enablement
+  name: Railiance Developer Enablement And CI/CD Templates
+  summary: S4 Developer Enablement layer of the Railiance OAS Stack — reusable CI/CD workflow templates,
+    developer portal paths, platform templates, SDKs, and buildpacks, using forge capabilities without
+    owning forge runtime.
+  vector: D3 / A2 / C2 / R1
+  domain: financials
+  status: draft
+  owner: railiance-enablement
+  path: registry/capabilities/capability.railiance.ci-enablement.md
+  tags:
+  - railiance
+  - ci-cd
+  - developer-enablement
+  - forgejo
+  consumption_modes:
+  - ci workflow template (copy/reference)
+  - cli (promote-repo-to-forgejo.sh)
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-fabric/registry/capabilities/capability.railiance.fabric-graph.md b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-fabric/registry/capabilities/capability.railiance.fabric-graph.md
new file mode 100644
index 0000000..798f15a
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-fabric/registry/capabilities/capability.railiance.fabric-graph.md
@@ -0,0 +1,122 @@
+---
+id: capability.railiance.fabric-graph
+name: Railiance Fabric Ecosystem Graph
+summary: 'Models the durable infrastructure-responsibility graph of the Railiance netkingdom: schemas,
+  discovery tools, registry services, graph queries, and State Hub export contracts for services, machines,
+  repos, deployables, endpoints, ownership, dependencies, and bindings.'
+owner: railiance-fabric
+status: draft
+domain: financials
+tags:
+- railiance
+- graph
+- ownership
+- discovery
+maturity:
+  discovery:
+    current: D3
+    target: D5
+    confidence: medium
+    rationale: README and SCOPE.md document the ecosystem graph model bounded by financial/operational
+      accountability (who pays, who is accountable), with king/lord/tenant ownership concepts referenced
+      in docs/FabricDiscoveryAndUpdate.md.
+  availability:
+    current: A1
+    target: A3
+    confidence: medium
+    rationale: Python package (`railiance-fabric`) providing a declaration loader and validator; consumed
+      as a library, no hosted service documented yet.
+external_evidence:
+  completeness:
+    level: C1
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - ecosystem graph declaration loader and validator
+    - schemas for services/machines/repos/deployables/endpoints/ownership/dependencies/bindings
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R0
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - discovery/rebuild/update-loop architecture documented as still evolving per docs/FabricDiscoveryAndUpdate.md
+discovery:
+  intent: Let repos declare services, capabilities, interfaces, dependencies, and bindings in source-controlled
+    files, and model the resulting durable infrastructure-responsibility graph across the Railiance ecosystem.
+  includes:
+  - ecosystem graph schema and declaration loader/validator
+  - State Hub export contracts for the graph
+  excludes:
+  - actual infrastructure provisioning (see railiance-infra, railiance-cluster)
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A1
+  target_level: A3
+  current_artifacts:
+  - Python package (`railiance-fabric`)
+  target_artifacts: []
+  consumption_modes:
+  - library import
+  - cli (validation)
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+evidence:
+  documentation:
+  - README.md
+  - SCOPE.md
+  - docs/FabricDiscoveryAndUpdate.md
+  tests:
+  - tests/
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - Railiance repos wanting to declare their place in the ecosystem ownership/dependency graph
+  not_recommended_for:
+  - needs for actual infrastructure provisioning (see railiance-infra/-cluster)
+  known_limitations:
+  - discovery/rebuild/update-loop architecture still evolving
+promotion_history: []
+---
+
+# Railiance Fabric Ecosystem Graph
+
+## Overview
+
+`railiance-fabric` models the durable infrastructure-responsibility graph of the Railiance netkingdom — who pays for infrastructure, who is accountable for it, and which durable interfaces create value across boundaries — via schemas, a declaration loader/validator, and State Hub export contracts.
+
+## Assessment notes
+
+### Discovery
+
+README and SCOPE.md document the ecosystem graph model bounded by financial/operational accountability (who pays, who is accountable), with king/lord/tenant ownership concepts referenced in docs/FabricDiscoveryAndUpdate.md.
+
+### Availability
+
+Python package (`railiance-fabric`) providing a declaration loader and validator; consumed as a library, no hosted service documented yet.
+
+### Completeness
+
+First-pass honest assessment from the REUSE-WP-0017 coverage campaign
+(reuse-surface). No external consumer feedback exists yet; levels reflect
+scope-vs-intent documentation quality, not internal code quality.
+
+### Reliability
+
+No production consumer telemetry exists yet; reliability level is
+intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [ ] Relations reference valid capability IDs (none yet)
+- [x] Index entry added in `registry/indexes/capabilities.yaml`
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-fabric/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-fabric/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..b87197e
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-fabric/registry/indexes/capabilities.yaml
@@ -0,0 +1,22 @@
+version: 1
+updated: '2026-07-06'
+domain: helix_forge
+capabilities:
+- id: capability.railiance.fabric-graph
+  name: Railiance Fabric Ecosystem Graph
+  summary: 'Models the durable infrastructure-responsibility graph of the Railiance netkingdom: schemas,
+    discovery tools, registry services, graph queries, and State Hub export contracts for services, machines,
+    repos, deployables, endpoints, ownership, dependencies, and bindings.'
+  vector: D3 / A1 / C1 / R0
+  domain: financials
+  status: draft
+  owner: railiance-fabric
+  path: registry/capabilities/capability.railiance.fabric-graph.md
+  tags:
+  - railiance
+  - graph
+  - ownership
+  - discovery
+  consumption_modes:
+  - library import
+  - cli (validation)
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-forge/registry/capabilities/capability.railiance.forge-infrastructure.md b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-forge/registry/capabilities/capability.railiance.forge-infrastructure.md
new file mode 100644
index 0000000..9dc21e2
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-forge/registry/capabilities/capability.railiance.forge-infrastructure.md
@@ -0,0 +1,129 @@
+---
+id: capability.railiance.forge-infrastructure
+name: Railiance Forge And Artifact Infrastructure
+summary: Source forge, registry, and automation-runner infrastructure for Railiance, separated out from
+  railiance-apps/railiance-enablement; covers current Gitea operation, the Forgejo migration, container/package
+  registries, and Actions runner substrate.
+owner: railiance-forge
+status: draft
+domain: financials
+tags:
+- railiance
+- forgejo
+- forge
+- ci-runner
+maturity:
+  discovery:
+    current: D3
+    target: D5
+    confidence: medium
+    rationale: README and SCOPE.md explicitly name 'current Gitea operation, future Forgejo migration,
+      container and package registries, Actions runner substrate, artifact lifecycle' as the scope; status
+      noted as 'active forge extraction' with canonical registry operation docs already landed.
+  availability:
+    current: A1
+    target: A3
+    confidence: medium
+    rationale: README explicitly states 'no live Helm deploy or Kubernetes apply was run as part of the
+      move' — documentation and operator targets exist, but this repo is mid-extraction; has .gitea CI
+      (not yet migrated to .forgejo itself, notably, despite owning the migration).
+external_evidence:
+  completeness:
+    level: C1
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - scope separation from railiance-apps/railiance-enablement documented
+    - canonical registry operation docs and runner ownership contracts
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R0
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - repo is actively being founded/extracted; no live deploy yet by its own account
+    - directly relevant to REUSE-WP-0019 but hasn't migrated its own CI to .forgejo/ yet
+discovery:
+  intent: Own source forge, artifact registry, and CI runner substrate responsibilities for Railiance,
+    separated from application (railiance-apps) and enablement (railiance-enablement) concerns, across
+    the Gitea-to-Forgejo transition.
+  includes:
+  - forge operation (current Gitea, migrating to Forgejo)
+  - container/package registries
+  - Actions runner substrate
+  - artifact lifecycle
+  excludes:
+  - application workload deployment (railiance-apps)
+  - CI/CD templates for consuming repos (railiance-enablement)
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A1
+  target_level: A3
+  current_artifacts:
+  - operator docs and tools/ (extraction in progress)
+  target_artifacts: []
+  consumption_modes:
+  - cli (operator tooling)
+  - documentation/runbooks
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+evidence:
+  documentation:
+  - README.md
+  - SCOPE.md
+  tests: []
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - Railiance operators managing forge/registry/runner infrastructure, especially during the Gitea-to-Forgejo
+    transition
+  not_recommended_for:
+  - treating this as production-stable — the repo's own README states the extraction is active and no
+    live deploy has run yet
+  known_limitations:
+  - actively being founded; no live Helm/k8s deploy has run as part of the extraction yet; own CI still
+    under .gitea/ pending its own Forgejo migration
+promotion_history: []
+---
+
+# Railiance Forge And Artifact Infrastructure
+
+## Overview
+
+`railiance-forge` is being founded to separate source forge, artifact registry, and CI/Actions runner responsibilities from `railiance-apps` and `railiance-enablement`. It directly owns the current Gitea operation and the future Forgejo migration — of particular relevance to REUSE-WP-0019 — though by its own account no live deploy has run yet.
+
+## Assessment notes
+
+### Discovery
+
+README and SCOPE.md explicitly name 'current Gitea operation, future Forgejo migration, container and package registries, Actions runner substrate, artifact lifecycle' as the scope; status noted as 'active forge extraction' with canonical registry operation docs already landed.
+
+### Availability
+
+README explicitly states 'no live Helm deploy or Kubernetes apply was run as part of the move' — documentation and operator targets exist, but this repo is mid-extraction; has .gitea CI (not yet migrated to .forgejo itself, notably, despite owning the migration).
+
+### Completeness
+
+First-pass honest assessment from the REUSE-WP-0017 coverage campaign
+(reuse-surface). No external consumer feedback exists yet; levels reflect
+scope-vs-intent documentation quality, not internal code quality.
+
+### Reliability
+
+No production consumer telemetry exists yet; reliability level is
+intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [ ] Relations reference valid capability IDs (none yet)
+- [x] Index entry added in `registry/indexes/capabilities.yaml`
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-forge/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-forge/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..6437991
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-forge/registry/indexes/capabilities.yaml
@@ -0,0 +1,22 @@
+version: 1
+updated: '2026-07-06'
+domain: helix_forge
+capabilities:
+- id: capability.railiance.forge-infrastructure
+  name: Railiance Forge And Artifact Infrastructure
+  summary: Source forge, registry, and automation-runner infrastructure for Railiance, separated out from
+    railiance-apps/railiance-enablement; covers current Gitea operation, the Forgejo migration, container/package
+    registries, and Actions runner substrate.
+  vector: D3 / A1 / C1 / R0
+  domain: financials
+  status: draft
+  owner: railiance-forge
+  path: registry/capabilities/capability.railiance.forge-infrastructure.md
+  tags:
+  - railiance
+  - forgejo
+  - forge
+  - ci-runner
+  consumption_modes:
+  - cli (operator tooling)
+  - documentation/runbooks
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-infra/registry/capabilities/capability.railiance.infra-provisioning.md b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-infra/registry/capabilities/capability.railiance.infra-provisioning.md
new file mode 100644
index 0000000..a66ab42
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-infra/registry/capabilities/capability.railiance.infra-provisioning.md
@@ -0,0 +1,131 @@
+---
+id: capability.railiance.infra-provisioning
+name: RailianceHosts Infrastructure Provisioning
+summary: Git-driven server provisioning and convergence for Hosteurope/Hetzner Cloud using Terraform,
+  cloud-init, and Ansible, with SOPS+age encrypted in-repo secrets and a servers.yaml inventory as source
+  of truth.
+owner: railiance-infra
+status: draft
+domain: financials
+tags:
+- railiance
+- terraform
+- ansible
+- infrastructure
+maturity:
+  discovery:
+    current: D4
+    target: D5
+    confidence: high
+    rationale: README documents a complete, concrete quickstart (clone, prerequisites, SOPS/age secrets
+      setup, provider setup, terraform apply, ansible convergence) with a specific inventory file (`inventory/servers.yaml`)
+      as source of truth — an unusually complete operational README among the swept repos.
+  availability:
+    current: A2
+    target: A3
+    confidence: high
+    rationale: Real ansible playbooks, terraform config, and scripts/tools present; has `.forgejo/` CI
+      already; documented as the S1 Infrastructure Substrate layer of the Railiance OAS Stack.
+external_evidence:
+  completeness:
+    level: C2
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - documented end-to-end quickstart from bare cloud account to converged servers
+    - SOPS+age encrypted secrets with a documented key-custody model
+    - inventory/servers.yaml as explicit source of truth
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R1
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - reproducibility not independently re-verified via a live provisioning run in this sweep
+discovery:
+  intent: Provision and manage servers on Hosteurope/Hetzner Cloud entirely from Git — Terraform for lifecycle,
+    cloud-init for first boot, Ansible for convergence — as the S1 Infrastructure Substrate of the Railiance
+    OAS Stack.
+  includes:
+  - Terraform server lifecycle management
+  - cloud-init first-boot configuration
+  - Ansible convergence playbooks
+  - SOPS+age encrypted secrets in-repo
+  excludes:
+  - Kubernetes cluster bootstrap on top of provisioned hosts (see railiance-cluster)
+  - platform services (see railiance-platform)
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A2
+  target_level: A3
+  current_artifacts:
+  - Terraform configs
+  - Ansible playbooks
+  - scripts/
+  - tools/
+  target_artifacts: []
+  consumption_modes:
+  - cli (terraform/ansible)
+  - gitops
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+evidence:
+  documentation:
+  - README.md
+  - SCOPE.md
+  tests:
+  - sbom-tools.yaml
+  - .forgejo/
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - operators provisioning Railiance bare-metal/cloud hosts from Git with encrypted-secret custody
+  not_recommended_for:
+  - needs above the OS/host substrate layer (see railiance-cluster for Kubernetes, railiance-platform
+    for shared services)
+  known_limitations:
+  - reproducibility not independently re-verified via a live provisioning run in this sweep
+promotion_history: []
+---
+
+# RailianceHosts Infrastructure Provisioning
+
+## Overview
+
+`railiance-infra` (RailianceHosts) is Git-driven automation for provisioning and converging servers on Hosteurope and Hetzner Cloud — Terraform for lifecycle, cloud-init for first boot, Ansible for convergence — with secrets encrypted in-repo via SOPS/age and `inventory/servers.yaml` as the source of truth. It is the S1 Infrastructure Substrate layer of the Railiance OAS Stack.
+
+## Assessment notes
+
+### Discovery
+
+README documents a complete, concrete quickstart (clone, prerequisites, SOPS/age secrets setup, provider setup, terraform apply, ansible convergence) with a specific inventory file (`inventory/servers.yaml`) as source of truth — an unusually complete operational README among the swept repos.
+
+### Availability
+
+Real ansible playbooks, terraform config, and scripts/tools present; has `.forgejo/` CI already; documented as the S1 Infrastructure Substrate layer of the Railiance OAS Stack.
+
+### Completeness
+
+First-pass honest assessment from the REUSE-WP-0017 coverage campaign
+(reuse-surface). No external consumer feedback exists yet; levels reflect
+scope-vs-intent documentation quality, not internal code quality.
+
+### Reliability
+
+No production consumer telemetry exists yet; reliability level is
+intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [ ] Relations reference valid capability IDs (none yet)
+- [x] Index entry added in `registry/indexes/capabilities.yaml`
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-infra/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-infra/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..6a463c2
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-infra/registry/indexes/capabilities.yaml
@@ -0,0 +1,22 @@
+version: 1
+updated: '2026-07-06'
+domain: helix_forge
+capabilities:
+- id: capability.railiance.infra-provisioning
+  name: RailianceHosts Infrastructure Provisioning
+  summary: Git-driven server provisioning and convergence for Hosteurope/Hetzner Cloud using Terraform,
+    cloud-init, and Ansible, with SOPS+age encrypted in-repo secrets and a servers.yaml inventory as source
+    of truth.
+  vector: D4 / A2 / C2 / R1
+  domain: financials
+  status: draft
+  owner: railiance-infra
+  path: registry/capabilities/capability.railiance.infra-provisioning.md
+  tags:
+  - railiance
+  - terraform
+  - ansible
+  - infrastructure
+  consumption_modes:
+  - cli (terraform/ansible)
+  - gitops
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-platform/registry/capabilities/capability.railiance.platform-services.md b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-platform/registry/capabilities/capability.railiance.platform-services.md
new file mode 100644
index 0000000..905bdbe
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-platform/registry/capabilities/capability.railiance.platform-services.md
@@ -0,0 +1,122 @@
+---
+id: capability.railiance.platform-services
+name: Railiance Platform Services
+summary: 'S3 Platform Services layer of the Railiance OAS Stack — shared cluster services: PostgreSQL
+  HA, Valkey cache, secret management, identity integration, and object storage.'
+owner: railiance-platform
+status: draft
+domain: financials
+tags:
+- railiance
+- platform
+- secrets
+- postgres
+maturity:
+  discovery:
+    current: D3
+    target: D4
+    confidence: medium
+    rationale: SCOPE.md places this repo precisely at S3 in the Railiance OAS Stack, scoped to shared
+      cluster services (PostgreSQL HA, Valkey, secrets, identity integration, object storage).
+  availability:
+    current: A2
+    target: A3
+    confidence: medium
+    rationale: No top-level package manifest, but ships real scripts/ (OpenBao/Vault apply/verify, credential-change
+      Python tooling) and tools/; has `.forgejo/` CI already in place.
+external_evidence:
+  completeness:
+    level: C1
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - OpenBao/Vault secret-management apply/verify scripting
+    - credential-change tooling
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R0
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - no top-level packaging; scripts/tools have no unified install path
+discovery:
+  intent: Own the shared platform services layer (Postgres HA, Valkey, secrets, identity integration,
+    object storage) that application and enablement layers depend on, without owning the underlying host/cluster
+    substrate.
+  includes:
+  - PostgreSQL HA and Valkey cache service management
+  - secret management (OpenBao/Vault) apply/verify tooling
+  - identity integration and object storage
+  excludes:
+  - host/cluster substrate provisioning (see railiance-infra, railiance-cluster)
+  - application workload deployment (see railiance-apps)
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A2
+  target_level: A3
+  current_artifacts:
+  - scripts/ (OpenBao/Vault, credential-change tooling)
+  - tools/
+  target_artifacts: []
+  consumption_modes:
+  - cli (shell/python scripts)
+relations:
+  depends_on: []
+  supports: []
+  related_to: []
+evidence:
+  documentation:
+  - SCOPE.md
+  tests:
+  - tests/
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - Railiance operators managing shared platform services (Postgres, Valkey, secrets, identity, storage)
+  not_recommended_for:
+  - needs at the host/cluster substrate layer (see railiance-infra/-cluster) or application layer (see
+    railiance-apps)
+  known_limitations:
+  - no unified top-level packaging across scripts/tools
+promotion_history: []
+---
+
+# Railiance Platform Services
+
+## Overview
+
+`railiance-platform` is the S3 Platform Services layer of the Railiance OAS Stack: shared cluster services including PostgreSQL HA, Valkey cache, OpenBao/Vault secret management, identity integration, and object storage, consumed by application and enablement layers above it.
+
+## Assessment notes
+
+### Discovery
+
+SCOPE.md places this repo precisely at S3 in the Railiance OAS Stack, scoped to shared cluster services (PostgreSQL HA, Valkey, secrets, identity integration, object storage).
+
+### Availability
+
+No top-level package manifest, but ships real scripts/ (OpenBao/Vault apply/verify, credential-change Python tooling) and tools/; has `.forgejo/` CI already in place.
+
+### Completeness
+
+First-pass honest assessment from the REUSE-WP-0017 coverage campaign
+(reuse-surface). No external consumer feedback exists yet; levels reflect
+scope-vs-intent documentation quality, not internal code quality.
+
+### Reliability
+
+No production consumer telemetry exists yet; reliability level is
+intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [ ] Relations reference valid capability IDs (none yet)
+- [x] Index entry added in `registry/indexes/capabilities.yaml`
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-platform/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-platform/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..3c28091
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/railiance-platform/registry/indexes/capabilities.yaml
@@ -0,0 +1,20 @@
+version: 1
+updated: '2026-07-06'
+domain: helix_forge
+capabilities:
+- id: capability.railiance.platform-services
+  name: Railiance Platform Services
+  summary: 'S3 Platform Services layer of the Railiance OAS Stack — shared cluster services: PostgreSQL
+    HA, Valkey cache, secret management, identity integration, and object storage.'
+  vector: D3 / A2 / C1 / R0
+  domain: financials
+  status: draft
+  owner: railiance-platform
+  path: registry/capabilities/capability.railiance.platform-services.md
+  tags:
+  - railiance
+  - platform
+  - secrets
+  - postgres
+  consumption_modes:
+  - cli (shell/python scripts)
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/reuse-surface/registry/capabilities/capability.registry.register.md b/docs/assessments/netkingdom-2026-10-14/registry-before/reuse-surface/registry/capabilities/capability.registry.register.md
new file mode 100644
index 0000000..05185f9
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/reuse-surface/registry/capabilities/capability.registry.register.md
@@ -0,0 +1,199 @@
+---
+id: capability.registry.register
+name: Capability Registration
+summary: Register a new capability so it becomes visible for planning and implementation reuse.
+owner: reuse-surface
+status: draft
+domain: helix_forge
+tags:
+  - registry
+  - governance
+  - meta
+
+maturity:
+  discovery:
+    current: D3
+    target: D5
+    confidence: medium
+    rationale: >
+      Core use case UC-RS-001 is documented in specs/UseCaseCatalog.md and the
+      registry model is bounded in INTENT.md, but concrete promotion workflows
+      are not yet grounded in registry artifacts.
+  availability:
+    current: A4
+    target: A5
+    confidence: medium
+    rationale: >
+      Local registry workflows use the reuse-surface CLI (A3). Federation repo
+      registration is also available through the hosted hub HTTP API at
+      reuse.coulomb.social (POST/PATCH /v1/repos), deployed and dogfood-tested
+      on Railiance01 (REUSE-WP-0011).
+
+external_evidence:
+  completeness:
+    level: C2
+    name: Partial
+    confidence: medium
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+      - capability IDs can be assigned in registry entries
+      - maturity vectors can be recorded at registration time
+      - CLI validate, query, and export support registry workflows
+      - promotion history can be recorded in entries
+      - federation repo registration via hosted hub API and hub CLI
+    broken_expectations:
+      - no automated duplicate detection yet
+    out_of_scope_expectations:
+      - hosting registered capabilities
+      - enforcing implementation architecture
+  reliability:
+    level: R3
+    name: Usable
+    confidence: medium
+    basis: consumer_quality_signals
+    known_reliability_risks:
+      - index drift still possible if authors skip validate
+      - CLI requires local venv install
+      - sibling repos cannot register until indexes publish raw URLs
+    evidence:
+      satisfied_signals:
+        - CI validate with fail-on-warnings on every push
+        - hub register/list/federated smoke on production reuse.coulomb.social
+        - pytest coverage for hub API and federation compose paths
+
+discovery:
+  intent: >
+    Make a capability candidate visible in the registry so humans and agents can
+    discover, assess, compare, and reuse it instead of rebuilding it in isolation.
+  includes:
+    - stable capability ID assignment
+    - initial discovery and availability classification
+    - explicit completeness and reliability placeholders
+    - evidence and relation references
+  excludes:
+    - implementing the registered capability
+    - certifying implementation quality
+    - operating runtime services for registered capabilities
+  assumptions:
+    - unregistered capabilities are invisible for registry-driven reuse
+    - low-maturity entries are acceptable when evidence gaps are explicit
+  use_cases:
+    - UC-RS-001
+  research_memos:
+    - specs/UseCaseCatalog.md
+    - specs/ProductRequirementsDocument.md
+
+availability:
+  current_level: A4
+  target_level: A5
+  current_artifacts:
+    - templates/capability-entry.template.md
+    - registry/indexes/capabilities.yaml
+    - reuse_surface/cli.py
+    - reuse_surface/hub/
+    - specs/FederationHubAPI.md
+    - https://reuse.coulomb.social
+  target_artifacts:
+    - packaged container release with documented SLO
+  consumption_modes:
+    - informational
+    - markdown authoring
+    - cli
+    - service API
+
+relations:
+  depends_on: []
+  supports:
+    - capability.feature-control.evaluate
+    - capability.identity.vocabulary-canonicalize
+  related_to:
+    - capability.registry.validate
+
+evidence:
+  documentation:
+    - INTENT.md
+    - specs/UseCaseCatalog.md
+    - specs/FederationHubAPI.md
+    - docs/deploy/reuse-kubernetes.md
+  tests:
+    - tests/test_hub.py
+    - tests/test_hub_sync.py
+    - .forgejo/workflows/ci.yml
+  consumer_feedback:
+    - >
+        reuse-surface dogfood (REUSE-WP-0011): production hub registration and
+        /v1/federated compose succeeded on Railiance01 without write-path
+        regressions after WP-0011 deploy.
+  bug_reports: []
+  incidents: []
+
+consumer_guidance:
+  recommended_for:
+    - making a new capability visible at D0/A0/C0/R0 with minimal friction
+    - seeding planning discussions before implementation exists
+  not_recommended_for:
+    - treating registry presence as proof of implementation readiness
+    - skipping explicit evidence for maturity promotion
+  known_limitations:
+    - manual index updates are required after adding an entry
+    - duplicate detection is guidance-only in the MVP
+
+promotion_history:
+  - date: "2026-06-14"
+    dimension: discovery
+    from: D0
+    to: D1
+    rationale: Added name, summary, and registry-first intent from INTENT.md.
+    author: reuse-surface
+  - date: "2026-06-15"
+    dimension: discovery
+    from: D1
+    to: D3
+    rationale: Bounded scope with UC-RS-001 and MVP registry artifacts in specs/.
+    author: reuse-surface
+  - date: "2026-06-15"
+    dimension: availability
+    from: A0
+    to: A3
+    rationale: reuse-surface CLI shipped validate, query, and export commands.
+    author: reuse-surface
+  - date: "2026-06-15"
+    dimension: availability
+    from: A3
+    to: A4
+    rationale: >
+      Hosted federation hub live at reuse.coulomb.social; hub register/update
+      via HTTP API and reuse-surface hub CLI; production deploy on Railiance01.
+    author: reuse-surface
+  - date: "2026-06-16"
+    dimension: reliability
+    from: R2
+    to: R3
+    rationale: >
+      CI gates, pytest hub/federation coverage, and production hub smoke support
+      normal registration workflows with documented limitations.
+    author: reuse-surface
+---
+
+# Capability Registration
+
+## Overview
+
+Registration is the entry point for reuse visibility. A capability that is not
+registered cannot be discovered through the registry surface, even if code or
+documentation exists elsewhere.
+
+## Current reuse mode
+
+**Local registry (A3 CLI):** add Markdown entries under `registry/capabilities/`,
+update `registry/indexes/capabilities.yaml`, run `reuse-surface validate`.
+
+**Federation registration (A4 API):** register published index URLs on the hosted
+hub (`reuse-surface hub register`, `POST /v1/repos`) for cross-repo discovery
+via `GET /v1/federated`.
+
+## Next promotion steps
+
+1. Attach concrete use cases and actors to reach D5.
+2. Package hub as a versioned container release with operator SLO (A5).
+3. Record consumer expectations and broken expectations as external evidence.
\ No newline at end of file
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/reuse-surface/registry/capabilities/capability.registry.validate.md b/docs/assessments/netkingdom-2026-10-14/registry-before/reuse-surface/registry/capabilities/capability.registry.validate.md
new file mode 100644
index 0000000..bd68d33
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/reuse-surface/registry/capabilities/capability.registry.validate.md
@@ -0,0 +1,107 @@
+---
+id: capability.registry.validate
+name: Registry Entry Validation
+summary: Validate capability registry entries against schema, index consistency, and relation integrity.
+owner: reuse-surface
+status: draft
+domain: helix_forge
+tags: [registry, validation, cli]
+
+maturity:
+  discovery:
+    current: D4
+    target: D5
+    confidence: medium
+    rationale: UC-RS-023 is implemented via reuse-surface validate with schema and drift checks.
+  availability:
+    current: A3
+    target: A3
+    confidence: high
+    rationale: Available as reuse-surface validate CLI command.
+
+external_evidence:
+  completeness:
+    level: C3
+    name: Functional Core
+    confidence: medium
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+      - schema validation for entry front matter
+      - index drift detection
+      - optional relation integrity checks
+    broken_expectations: []
+    out_of_scope_expectations:
+      - runtime validation of registered capability implementations
+  reliability:
+    level: R3
+    name: Usable
+    confidence: medium
+    basis: consumer_quality_signals
+    known_reliability_risks:
+      - requires local venv install
+      - relation warnings require explicit --relations flag
+    evidence:
+      satisfied_signals:
+        - validate --relations --fail-on-warnings in CI
+        - tests/test_registry.py schema and drift coverage
+
+discovery:
+  intent: Keep registry data structurally sound so agents and humans can trust discovery metadata.
+  includes:
+    - JSON Schema validation
+    - index drift warnings
+    - relation reference checks
+  excludes:
+    - validating implementation code in other repos
+  use_cases:
+    - UC-RS-023
+  research_memos:
+    - specs/UseCaseCatalog.md
+
+availability:
+  current_level: A3
+  target_level: A3
+  current_artifacts:
+    - reuse_surface/cli.py
+    - schemas/capability.schema.yaml
+  consumption_modes:
+    - cli
+
+relations:
+  depends_on:
+    - capability.registry.register
+  supports: []
+  related_to:
+    - capability.registry.register
+
+evidence:
+  documentation:
+    - tools/README.md
+    - .forgejo/workflows/ci.yml
+  tests:
+    - tests/test_registry.py
+  consumer_feedback:
+    - >
+        reuse-surface CI: registry changes fail when schema validation or relation
+        checks warn with --fail-on-warnings, giving agents a dependable pre-merge gate.
+
+consumer_guidance:
+  recommended_for:
+    - pre-commit and CI validation of registry changes
+  not_recommended_for:
+    - certifying business correctness of capability claims
+  known_limitations:
+    - warnings do not fail CI unless --fail-on-warnings is set
+
+promotion_history:
+  - date: "2026-06-16"
+    dimension: reliability
+    from: R2
+    to: R3
+    rationale: CI fail-on-warnings and pytest registry coverage support dependable validation.
+    author: reuse-surface
+---
+
+# Registry Entry Validation
+
+Validates registry shape and consistency through the reuse-surface CLI.
\ No newline at end of file
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/reuse-surface/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/reuse-surface/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..21ca35a
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/reuse-surface/registry/indexes/capabilities.yaml
@@ -0,0 +1,49 @@
+# Manually maintained capability index for humans and agents.
+version: 1
+updated: "2026-10-13"
+domain: helix_forge
+capabilities:
+  - id: capability.infotech.headless-browser
+    name: Headless Browser Automation
+    summary: >-
+      Headless browser automation, screenshots and keyboard trials through
+      rapp-playwright 0.1.0 (Playwright 1.64.0, Chromium 156.0.8078.4).
+      Published A5 local container; managed Railiance admission is pending.
+      Download the Python 3.10+ standalone client from
+      https://forgejo.coulomb.social/coulomb/rapp-playwright/raw/commit/8831a05aeba5ce588f3b395ade676dde2a151c5d/client/rapp_playwright.py
+      and run `python3 rapp_playwright.py --url http://127.0.0.1:18083 preflight`,
+      then `python3 rapp_playwright.py --url http://127.0.0.1:18083 trial --out trial-01`
+      with a fresh output directory. This endpoint was verified locally on 2026-10-13
+      and is ephemeral; it installs no browser for the caller. If unreachable,
+      follow the local container setup in the capability card or adapt its A2 source
+      examples; this is an availability gap on the existing capability.
+      Contract: https://forgejo.coulomb.social/coulomb/rapp-playwright/src/commit/8831a05aeba5ce588f3b395ade676dde2a151c5d/docs/consumer-contract.md.
+    vector: D3 / A5 / C2 / R2
+    domain: infotech
+    status: reviewed
+    owner: reuse-surface
+    path: registry/capabilities/capability.infotech.headless-browser.md
+    tags: [headless, browser, automation, playwright, chromium, testing, screenshots, extraction, firefox, webkit, selenium, puppeteer]
+    consumption_modes: [informational, source adaptation, JavaScript library, Python library, cli, service API, container]
+
+  - id: capability.registry.register
+    name: Capability Registration
+    summary: Register a new capability so it becomes visible for planning and implementation reuse.
+    vector: D3 / A4 / C2 / R3
+    domain: helix_forge
+    status: draft
+    owner: reuse-surface
+    path: registry/capabilities/capability.registry.register.md
+    tags: [registry, governance, meta]
+    consumption_modes: [informational, markdown authoring, cli, service API]
+
+  - id: capability.registry.validate
+    name: Registry Entry Validation
+    summary: Validate capability registry entries against schema, index consistency, and relation integrity.
+    vector: D4 / A3 / C3 / R3
+    domain: helix_forge
+    status: draft
+    owner: reuse-surface
+    path: registry/capabilities/capability.registry.validate.md
+    tags: [registry, validation, cli]
+    consumption_modes: [cli]
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/runbook-tutorials/registry/capabilities/capability.infotech.runbook-tutorials.md b/docs/assessments/netkingdom-2026-10-14/registry-before/runbook-tutorials/registry/capabilities/capability.infotech.runbook-tutorials.md
new file mode 100644
index 0000000..b2e6d57
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/runbook-tutorials/registry/capabilities/capability.infotech.runbook-tutorials.md
@@ -0,0 +1,18 @@
+---
+id: capability.infotech.runbook-tutorials
+name: Runbook-tutorial engine
+summary: Engine, local UI and CLI for guided, parameterized operator runbooks: pack specification and validators, runs with evidence and locked records, maturity, attribute sets, projects and whole-project runs. Packs live in the repos that own the procedure.
+owner: runbook-tutorials
+status: active
+domain: infotech
+tags:
+  - runbook
+  - tutorial
+  - operator
+  - guided
+---
+
+Working: specifications `runbook-pack/v0.1` and `v0.2` with validators, the engine and local UI, projects and project templates, and the `rtut`
+CLI (see `SCOPE.md`). Not built by decision: execution of steps, a cross-repository pack index, a feedback assistant (`workplans/RBT-WP-0006`).
+Only the NetKingdom repository provides packs so far, and its three v0.2 packs have not had their first attended run, so this capability is
+`active` but has no operational evidence yet. The fleet maturity vector is not assessed here: it needs the fleet's assessment method.
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/runbook-tutorials/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/runbook-tutorials/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..4d9dd8d
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/runbook-tutorials/registry/indexes/capabilities.yaml
@@ -0,0 +1,13 @@
+version: 1
+updated: '2026-09-29'
+domain: infotech
+capabilities:
+  - id: capability.infotech.runbook-tutorials
+    name: Runbook-tutorial engine
+    summary: Engine, local UI and CLI for guided, parameterized operator runbooks; packs live in the repos that own the procedure.
+    domain: infotech
+    status: active
+    owner: runbook-tutorials
+    path: registry/capabilities/capability.infotech.runbook-tutorials.md
+    tags: [runbook, tutorial, operator, guided]
+    consumption_modes: [git clone, cli]
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/sand-boxer/registry/capabilities/execution.sandbox-provision.md b/docs/assessments/netkingdom-2026-10-14/registry-before/sand-boxer/registry/capabilities/execution.sandbox-provision.md
new file mode 100644
index 0000000..7921f0b
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/sand-boxer/registry/capabilities/execution.sandbox-provision.md
@@ -0,0 +1,48 @@
+---
+id: capability.execution.sandbox-provision
+name: Sandbox Provisioning
+summary: Isolated execution environments for agentic development, e2e testing, and bounded automations — profile-based provision, TTL teardown, and State Hub lifecycle registration.
+owner: sand-boxer
+status: draft
+domain: infotech
+tags: [sandbox, isolation, provision, e2e, agentic, execution, profile]
+
+maturity:
+  discovery:
+    current: D5
+    target: D6
+    confidence: high
+    rationale: >
+      Charter (INTENT.md), meta-framework spec, extension SDK, integration docs,
+      and research synthesis. Capability indexed in registry/.
+  availability:
+    current: A5
+    target: A5
+    confidence: high
+    rationale: >
+      CLI v0 (create/destroy/snapshot/TTL), HTTP API, CoulombCore remote smoke.
+      Cloud adapters E2B/Modal + routing + credits (SAND-WP-0010).
+
+external_evidence:
+  completeness:
+    level: C5
+    name: Mature
+    confidence: high
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+      - profile-based create/destroy/snapshot/restore via CLI
+      - TTL extend and expire/reap (SAND-WP-0009)
+      - E2B and Modal cloud adapters with BYOK (SAND-WP-0010)
+      - State Hub lifecycle events on transitions
+      - wise-validator and the-custodian migration arc complete
+      - extension SDK with compose-ssh, vm-packer attach, saas-stub, e2b, modal
+    broken_expectations:
+      - sandboxer01 dedicated host not live (CoulombCore interim)
+    out_of_scope_expectations:
+      - agent harness and tool orchestration (glas-harness)
+      - e2e test semantics (wise-validator)
+
+consumption_modes:
+  - CLI (sandboxer)
+  - core library (Python)
+  - HTTP API (uvicorn sandboxer.api.app:app)
\ No newline at end of file
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/sand-boxer/registry/indexes/capabilities.yaml b/docs/assessments/netkingdom-2026-10-14/registry-before/sand-boxer/registry/indexes/capabilities.yaml
new file mode 100644
index 0000000..bd661a3
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/sand-boxer/registry/indexes/capabilities.yaml
@@ -0,0 +1,23 @@
+version: 1
+updated: '2026-06-22'
+domain: infotech
+capabilities:
+- id: capability.execution.sandbox-provision
+  name: Sandbox Provisioning
+  summary: Isolated execution environments for agentic development, e2e testing, and bounded automations — profile-based provision, TTL teardown, and State Hub lifecycle registration.
+  vector: D4 / A2 / C2 / R1
+  domain: infotech
+  status: draft
+  owner: sand-boxer
+  path: registry/capabilities/execution.sandbox-provision.md
+  tags:
+  - sandbox
+  - isolation
+  - provision
+  - e2e
+  - agentic
+  - execution
+  - profile
+  consumption_modes:
+  - CLI
+  - core library
\ No newline at end of file
diff --git a/docs/assessments/netkingdom-2026-10-14/registry-before/sbom-nexus/registry/capabilities/capability.infotech.sbom-management.md b/docs/assessments/netkingdom-2026-10-14/registry-before/sbom-nexus/registry/capabilities/capability.infotech.sbom-management.md
new file mode 100644
index 0000000..5531a5f
--- /dev/null
+++ b/docs/assessments/netkingdom-2026-10-14/registry-before/sbom-nexus/registry/capabilities/capability.infotech.sbom-management.md
@@ -0,0 +1,19 @@
+---
+id: capability.infotech.sbom-management
+type: capability
+name: SBOM management
+repo: sbom-nexus
+domain: infotech
+status: emerging
+interfaces:
+  - http
+  - cli
+---
+
+# SBOM management
+
+Capture repository dependency evidence, preserve immutable SBOM snapshot
+history, query current inventory and licence signals, and select a deterministic
+bounded fleet catch-up queue.
+
+The extraction interface is documented in `ProductRequirementsDocument.md`.