the-custodian/docs/assessments/2026-09-08-helixforge-factory.md

# Coulomb, HelixForge and Railiance: factory readiness assessment

Date: 2026-09-08. Assessor: Codex acting as the-custodian.
Scope: the registered Coulomb estate, with particular attention to the HelixForge
delivery path on Railiance. This is an assessment and a proposed programme;
it does not authorize deployment, credentials, reprioritization of other owners,
or unattended execution.

**Assessment:** the estate has enough substantial components to justify an
integration pilot. It does not yet have reviewed evidence that its current
governed execution path repeatedly delivers useful software on Railiance.
The principal constraint is completing and operating the interfaces between
existing components. Starting another general framework would increase the
coordination burden before resolving that constraint.

The recommended outcome is an **internal, single-tenant software factory**:
human intent becomes a bounded capability contract; an authorized agent produces
a reviewable change; independent validation gates an immutable artifact and an
authorized Railiance release; outcome and cost evidence inform the next change.
Autonomous production promotion and external multi-tenant service are later
maturity levels. HelixForge's existing discovery, architecture, and reuse goals
remain part of acceptance: a bot making commits alone does not meet them.

## What was examined, and what the numbers mean

The live State Hub returned 135 repositories, 1,314 workplans and 7,102 tasks.
The separate task-count endpoint also totaled 7,102. Requests used canonical
`/workplans/` and `/tasks/` routes; the task list's default has no pagination
limit in the inspected OpenAPI contract. The inbox for `the-custodian` was empty.
The initial portfolio capture preceded creation of this assessment.

All **94 non-retired open Hub workplans** were resolved to local source files
by UUID or canonical identifier, and their workplan statuses agreed. This
validates the workplan count against available checkouts, not each completion
claim or deployment. Detailed integration review covered the current owner
plans, source contracts, and recorded production evidence, particularly the
September 4–8 work. No live cluster acceptance run, credential access, or
independent security audit was performed in this assessment.

The eighteen principal checkouts' revisions and working-copy states are captured
in [checkout provenance](2026-09-08-helixforge-factory/checkout-provenance.json).
Their cached tracking branches showed no ahead/behind difference; no fetch was
performed. State Hub had existing local changes. Under
[ADR-012](../../canon/architecture/adr-012-projection-source-and-preliminary-overlay.md),
local evidence cannot substitute for a fresh Forge-derived production baseline.

Raw Hub counts are **98 open plans: 44 active, 28 blocked, 15 proposed, six ready,
five backlog**. Four open rows have explicitly retired identities. Excluding
those rows gives the following planning baseline; it is not a silent repair of
the Hub or a claim that all remaining effort is necessary.

| Workplan status | Non-retired count |
| --- | ---: |
| Active | 41 |
| Blocked | 27 |
| Proposed | 15 |
| Ready | 6 |
| Backlog | 5 |
| **Open total** | **94** |

The raw 98 span 49 registered repos. The 94 canonical open plans contain
**264 open tasks: 136 todo, 28 progress, 100 wait**. Across *all* Hub workplans
there are 287 open tasks, including seven attached to retired open identities
and sixteen attached to terminal workplans. Those extra 23 must not be treated
automatically as new implementation demand.

One additional local active record, `kings-guard/KG-WP-0005`, was absent from the
captured Hub workplan list. The wider local scan encountered historic terminal
spellings (`done`, `completed`), shared paths, unavailable registered paths and
legacy YAML dialects. Accordingly, this report uses the verified Hub cohort,
not a purported complete source-only fleet census. Age of a declared update or
sync is not elapsed blocker time; blocker transition history was not measured.

Evidence and reproducible definitions: [baseline](2026-09-08-helixforge-factory/baseline.json),
[98-row inventory](2026-09-08-helixforge-factory/open-workplans.csv),
[source records](2026-09-08-helixforge-factory/source-records.json), and
[methodology](2026-09-08-helixforge-factory/README.md).

## Where the load sits

These are disjoint analytical cohorts, not a proposed repository reclassification.
All statuses in this table exclude retired identities.

| Cohort | Open plans | Active | Blocked | Open tasks |
| --- | ---: | ---: | ---: | ---: |
| Identity, policy, custody and audit | 35 | 14 | 13 | 93 |
| Railiance runtime, packages and recovery | 23 | 10 | 10 | 43 |
| Agent execution and coordination | 9 | 7 | 2 | 15 |
| Hub consolidation and work projection | 7 | 2 | 1 | 26 |
| Publishing and community | 7 | 4 | 0 | 38 |
| Other product, commercial and research work | 13 | 4 | 1 | 49 |
| **Total** | **94** | **41** | **27** | **264** |

Identity/security and Railiance account for **58/94 open plans and 23/27 blocked
plans**. The direct agent-execution cohort has only fifteen open tasks spread
across nine plans. This concentration suggests that dependency closure and live
integration offer more immediate value than expanding the runtime feature list.
It does not establish engineering effort: task counts have no common size.

There is additional intake load: **54 open and eight routed intakes**, including
31 open intakes marked `origin: residual`. Routed intakes may already have
child workplans; adding them to the 94 would double-count some demand.
The [cohort membership](2026-09-08-helixforge-factory/cohorts.json) and full
inventory make the boundaries and individual blocked plans inspectable.

## Existing capabilities worth building on

| Capability | Evidence and practical limit |
| --- | --- |
| HelixForge intent and reusable operating prompts | [INTENT](../../../helix-forge/INTENT.md) defines discovery, capability contracts, architecture validation, realization and evolution. [HF-WP-0005](../../../helix-forge/workplans/HF-WP-0005-reusable-prompt-collection.md) delivered seven prompt packages and two fragments. All five HelixForge workplans are terminal; none owns factory acceptance. Its [SCOPE](../../../helix-forge/SCOPE.md) still describes a concept repository and references the retired Inter-Hub/nested State Hub structure. |
| Forgejo CI and artifact publication | [Runner substrate](../../../railiance-forge/docs/forgejo-actions-runner-substrate.md) records an in-cluster Railiance runner. [Enablement templates](../../../railiance-enablement/docs/forgejo-actions-workflow-templates.md) provide existing build/publish patterns. REINAH-WP-0003 records a recent real CI contract gate. There is no need to propose installing a forge or generic CI from scratch. |
| Scheduled work and repository mutation | [rein-aharness SCOPE](../../../rein-aharness/SCOPE.md) records the real railiance01 user-service claim loop, transaction acceptance and durable terminal-close outbox. Its Kubernetes Deployment runs `sleep infinity`; pod existence is not worker execution evidence. Historical Claude and deterministic clone/commit proofs do not certify the present profile. |
| Governed profile and sandbox boundary | [SAND-WP-0015](../../../sand-boxer/workplans/SAND-WP-0015-bwrap-runtime-and-private-state.md) records real bwrap startup, private state, constrained proxy transport, synthetic credential delivery and a pinned Claude candidate. The candidate remains a local `/tmp` artifact; startup is not a provider request or production installation. |
| Shared runtime substrate | [RMASTER-WP-0020](../../../railiance-master/workplans/RMASTER-WP-0020-openbao-migration-to-reef-railiance.md) records completed OpenBao restore, consumer migration, cutover and reversible source retirement. [RPF-WP-0038](../../../railiance-platform/workplans/RPF-WP-0038-forgejo-scaleway-primary-coverage.md) records successful isolated Forgejo recovery. Remaining cleanup, scheduled custody and retention work must be distinguished from initial deployment. |

## Inefficiencies to tackle

### 1. The queue describes work better than it dispatches it

Only **four of 94** dependency queries returned structured edges, four edges in
total. The owner plans contain many more dependencies in prose. Every one of
the **105 waiting tasks** in the fleet has an empty structured `blocking_reason`.
All 287 open tasks have no API `assignee`; workplans often name owners in
frontmatter or prose, so this is a dispatchability gap, not proof of ownerless work.
**23 of 41 active plans have no task in progress**. That is a review signal,
not an automatic instruction to close or demote them.

All 94 canonical plans show `manual` execution and launch metadata. This does
**not** mean no automation exists: [STATE-WP-0079](../../../state-hub/workplans/STATE-WP-0079-retirement-strangler.md)
records that the old workplan launch route was retired because Activity Core
never consumed it. Factory work must enter the supported ActivityDefinition /
`ops_run` route with explicit admission. Toggling a Hub workplan flag cannot
create an execution path.

**Remedy:** initially normalize only the selected factory chain. Each blocking
task needs the supplying owner task, precise return evidence, next action,
review/expiry condition and whether human action is actually required. Preserve
that information in owning source files and project dependency references; use
existing projection support where available. Do not add another scheduler or
permanent queue to the retiring State Hub. Generate views from those records.

### 2. Human attention is consumed by stale and incomplete signals

Of nineteen `needs_human` flags, **seventeen are terminal tasks** (sixteen done,
one cancelled). Only two are on open tasks. Meanwhile the current owner records
describe real attended custody and verification needs that do not appear in
that queue. Thirteen canonical open plans have no `backing_synced_at`; another
27 have a recorded sync older than seven days. Source status agreement makes
this a provenance/freshness problem, not proof that forty plans are wrong.

Four retired open rows inflate the portfolio: three historical Railiance
Platform identities and the Custodian's retired August 25 ad-hoc identity.
Three non-retired terminal plans also contain open tasks (`SAND-WP-0003`,
`SAND-WP-0005`, `REUSE-WP-0019`); verify source and residual disposition before
changing anything.

The session-close `statehub fix-consistency` check independently returned
**13 assessment failures and 63 warnings** in existing Custodian records:
ten archived CUST-WP-0054 task UUID references, two archived workplan UUID
references, and the retired open ad-hoc identity account for the failures.
It reported zero automation errors and synchronized 75/77 bindings, but it did
**not** pass. The [check receipt](2026-09-08-helixforge-factory/consistency-check.json)
is additional evidence that a healthy API and matching open-plan statuses are
insufficient to establish full historical projection consistency. Existing live
intake [CUST-IN-0017](../../intakes.md) already owns these exact failures and the
prefix conflict; return this observation there during adoption rather than
creating another cleanup workplan.

**Remedy:** review terminal flags and retired identities once through the owning
reconciliation path; preserve history. Present a small, prepared human queue of
actual decisions and attended actions. Batch compatible owner ceremonies when
their prerequisites are ready, with separate grants and receipts. Measure
operator minutes and repeated handoffs, not just the number of closed plans.

### 3. Integration contracts are proved too late

[SECRETS-WP-0009](../../../secrets-engine/workplans/SECRETS-WP-0009-glas-claude-native-delivery.md)
records three concrete discoveries from real owner integration: a missing
tenant, disagreement over normalized request digests, and fixtures that rebuilt
inputs from the expected enriched output. The September 7 correction says the
digest normalization rule was already published; that issue is resolved and
must not be charged again as an outstanding flex-auth dependency.

[AUDIT-WP-0009-T09](../../../audit-core/workplans/AUDIT-WP-0009-evidence-role-conformance.md)
was reprioritized after an inverted dependency was recognized: approval-engine
could not start without its audit sender, although the task had been described
as nonblocking because approval-engine was not yet emitting. The correction is
already recorded. Retelling it as a current unresolved priority dispute would
create more coordination work.

**Remedy:** pin a small cross-owner compatibility set and test real request,
response, credential, admission and completion artifacts early. Require both a
successful path and meaningful denial/retry cases. Consume the existing Glas
handoff packet; do not open a second round of generic owner interviews.

### 4. Locally finished components obscure the missing operating result

[GLAS-WP-0012](../../../glas-harness/workplans/GLAS-WP-0012-first-local-profile-production-proof.md)
is still blocked on first real-profile acceptance; [GLAS-WP-0015](../../../glas-harness/workplans/GLAS-WP-0015-production-dependency-coordination.md)
already coordinates its seven owner interfaces. [APPROVAL-WP-0002](../../../approval-engine/workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md)
has a published immutable image, but its September 7 review records no deployed
service and outstanding identity/audit inputs.

**Remedy:** use one acceptance ledger linking existing child work and three
distinct evidence levels: source implemented, deployed and exercised, useful
outcome accepted. Close the project only at the third level with repeated
operating evidence. A model-created `SMOKE.md` is a boundary proof; follow it
with a user-valued capability change, release and reuse evidence.

### 5. Concurrent migrations and presentation work compete with the factory path

Hub replacement, security-layer amendments, repository renames, HA, retained
CoulombCore cleanup and publication have legitimate owners and goals. They are
not all prerequisites for one internal factory. The community/publication
cohort alone has 38 open tasks; its commercial importance should be evaluated
explicitly alongside the fifteen direct execution tasks, rather than inferred
from a shared HelixForge name.

**Remedy:** adopt a factory work-in-progress limit: one integrated delivery
item plus at most two prerequisite closures at a time, with an explicit incident
exception. Keep essential operations and security response running. Defer
optional factory expansion, broad renames, full HA, additional model/runtime
families and community automation until the pilot demonstrates delivery. Retain
the current healthy State Hub service while owner migrations meet their own
gates. Avoid another all-estate rename or documentation cleanup programme.

## The actual critical path

This graph is the proposed acceptance sequence, reconstructed from the owner
records. It is not a claim that all these edges are already represented in the
Hub. The local Glas proof must be followed by deployment-specific Railiance
proof; its localhost profile cannot be promoted by changing a label.

```mermaid
flowchart TD
    C[Admit service-client custody] --> K[Prove KeyCape approval clients]
    A[Admit audit sender and delivery] --> P[Deploy and verify approval-engine]
    K --> P
    P --> S[Activate native credential lane]
    S --> G[Accept real Glas profile]
    R[Install pinned runtime and owner policy] --> G
    G --> H[Prove current worker on Railiance]
    Q[Deploy queue and repository contracts] --> H
    H --> D[Useful capability change and independent CI]
    D --> B[Immutable artifact and governed Railiance release]
    B --> O[Repeat deliveries, recovery and cost observation]
```

| Priority / gate | Existing ownership | Required return and boundary |
| --- | --- | --- |
| Immediate operational risk | `NK-WP-0033`, `NK-WP-0034`, `RPF-WP-0027` | Finish the repaired identity verification receipt and explicit predecessor disposition. Assess overlap before extending a privileged factory lane. The recorded defect is concrete; do not claim the full credential exposure incident closed. |
| Factory identity and audit admission | `KEY-WP-0013-T02`, `AUDIT-WP-0009-T09`, `APPROVAL-WP-0002-T01/T03`; custody owner `railiance-platform` | Exact service clients and consumer-side delivery, agreed audit tenant/redaction policy, admitted sender credential, rollout and restart/restore proof. Glas's platform handoff still lacks a recorded custody return. Link the exact custody record before activation; do not invent a grant from a generic routing match. |
| Native execution credentials | `SECRETS-WP-0009-T03`, linked `SECRETS-WP-0007/0008` | September 7 evidence narrows the remaining external dependency to the approval claim endpoint. Verify claim/consume and actual protected delivery once the service exists. Keep broader engine conformance separate unless its acceptance actually gates this action. |
| Profile acceptance | `SAND-WP-0015-T04`, `GLAS-WP-0012-T02–T06`; coordinator `GLAS-WP-0015-T03` | Protected installation, exact actor/project/profile binding, real provider execution, artifact, denial and teardown receipts. Pinned binary startup and owner transport are already evidenced at candidate level. |
| Railiance worker closure | `REINAH-WP-0003-T05/T06`, `ACTIVITY-WP-0032-T05`, `ACTIVITY-WP-0035-T08`, `ACTIVITY-WP-0036-T04` | Current deployed versions, natural claim/heartbeat/close, controlled late-close rejection, repository acceptance and replay/cleanup. Source heartbeat timing was corrected; return the production trace. |
| Repeated software delivery | HelixForge acceptance owner; source repo; `railiance-enablement`, `railiance-forge`, concrete `rapp-*` / `reef-*` owners | Adopt a bounded implementation record for the chosen pilot after scope selection. Join intent → granted change → CI → immutable artifact → authorized release → service smoke and reuse record. Existing plans do not yet own this whole result. |

Admission does not require completing the entire audit roadmap: AUDIT-WP-0009
explicitly separates sender admission from attestation freshness, heartbeat and
reconciliation claims. Full operating acceptance must address those later
obligations or accurately bound its claims. Likewise OpenBao source deletion,
public UI retraction and factory credential delivery are distinct gates.

## Proposed workplan and first operating target

The complete draft is [HFACT-WP-0001](../proposals/prj-helixforge-factory/workplans/HFACT-WP-0001-establish-internal-factory.md),
with [goal and measurable gates](../proposals/prj-helixforge-factory/GOAL.md).
It is prepared as a dedicated project-repository packet, following
[ADR-005](../../canon/architecture/adr-005-cross-repo-workplans-project-repos.md).
The packet is retained here for review; it has not been instantiated or
registered as another live programme. Existing owner statuses remain intact.
Project adoption is its first task. The permanent product home remains
`helix-forge`; the temporary project coordinates only the missing factory outcome.

Suggested sequencing, with estimates rather than commitments:

| Stage | Completion condition | Rough effort |
| --- | --- | --- |
| Select and normalize | One internal tenant, one pilot service/capability, acceptance owner, execution/spend envelope and exact prerequisite records | 2–3 engineering days |
| Close owner prerequisites | Identity/audit/approval/native delivery and installed runtime proven through current contracts | 4–8 engineering days, plus owner/attended waiting time |
| Prove delivery on Railiance | Current profile and worker, useful code change, independent CI, artifact, authorized release and rollback | 5–8 engineering days |
| Establish operation | Recovery and observability proof, repeatable intake, measurements and acceptance review | 3–5 engineering days plus a 14-calendar-day observation window |

This is roughly **14–24 engineering days plus observation and external waiting**.
A 4–6-week planning window is plausible with two coordinated implementation
tracks and available owners; there is no measured delivery rate or capacity
commitment that makes it a forecast. Do not translate 264 task rows into dates.

Proposed exit: at least five genuinely useful accepted changes across two
repositories during fourteen days, at least one software service release on
Railiance, and a capability reused or consumed by the second repository.
Record every admitted attempt; target ≥80% accepted without operator repair,
≤30 minutes median human handling per accepted change, and ≤30 minutes/day
routine factory operation. Measure security/recovery ceremonies separately and
also include them in total founder load. These are proposed targets, not current
performance. Use `UPC-WP-0003` for the broader company-load objective; a short
factory pilot cannot prove its ≥30-day commercial/company gates.

The first next action is therefore a **prepared custody and audit admission
closure through GLAS-WP-0015**, while the factory owner selects the first useful
capability and its acceptance test. Neither action requires reopening resolved
tenant/digest questions or completing all 94 open plans.


Execution subsequently authorized on 2026-09-08: see the
[implementation return](2026-09-08-helixforge-factory-followthrough.md) and
[current project pointer](../proposals/prj-helixforge-factory/README.md). The
baseline above remains the dated assessment, not a refreshed fleet total.