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. Their cached tracking branches showed no ahead/behind difference; no fetch was performed. State Hub had existing local changes. Under ADR-012, 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, 98-row inventory, source records, and methodology.

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 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 defines discovery, capability contracts, architecture validation, realization and evolution. HF-WP-0005 delivered seven prompt packages and two fragments. All five HelixForge workplans are terminal; none owns factory acceptance. Its SCOPE still describes a concept repository and references the retired Inter-Hub/nested State Hub structure.
Forgejo CI and artifact publication	Runner substrate records an in-cluster Railiance runner. Enablement templates 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 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 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 records completed OpenBao restore, consumer migration, cutover and reversible source retirement. RPF-WP-0038 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 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 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 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 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 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 is still blocked on first real-profile acceptance; GLAS-WP-0015 already coordinates its seven owner interfaces. APPROVAL-WP-0002 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.

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, with goal and measurable gates. It is prepared as a dedicated project-repository packet, following ADR-005. 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 and current project pointer. The baseline above remains the dated assessment, not a refreshed fleet total.