the-custodian/docs/proposals/prj-helixforge-factory/workplans/HFACT-WP-0001-establish-internal-factory.md

---
id: HFACT-WP-0001
type: workplan
title: "Establish the internal HelixForge software factory on Railiance"
domain: infotech
repo: prj-helixforge-factory
status: proposed
owner: the-custodian
topic_slug: infotech
created: "2026-09-08"
updated: "2026-09-08"
related:
  - GLAS-WP-0012
  - GLAS-WP-0015
  - SAND-WP-0015
  - REINAH-WP-0003
  - ACTIVITY-WP-0032
  - ACTIVITY-WP-0035
  - ACTIVITY-WP-0036
  - KEY-WP-0013
  - APPROVAL-WP-0002
  - SECRETS-WP-0009
  - AUDIT-WP-0009
  - RPF-WP-0038
  - UPC-WP-0003
---

# Establish the internal factory

**Proposal only.** Prepared in the Custodian on 2026-09-08; not yet a registered
project or an execution authorization. Prefix allocation and adoption are T01.
The assessment is complete; the eight tasks below are future factory work.

The [goal](../GOAL.md) defines success. The [dependency map](../dependency-map.md)
identifies existing work to consume. This workplan owns integration acceptance
and handoff; it neither replaces nor copies child implementation plans.

Recommended sequence:

```text
T01 → T02
T01 → T03 ─┐
T01 → T04 ─┴→ T05 → T06 → T08
T01 → T07 ───────────────→ T08
```

T04 runtime preparation can advance before T03 finishes; real model acceptance
cannot. T07 recovery preparation can advance early; its live proof depends on
the deployed T05/T06 configuration. T02 is complete before regular scheduling.

## T01 — Adopt the project and select the first valuable capability

```task
id: HFACT-WP-0001-T01
status: todo
priority: high
assignee: the-custodian
```

Coordinator: the-custodian. Acceptance: the HelixForge product owner and the
operator responsible for Railiance. Estimated effort: 1–2 engineering days.

Review this packet against current published owner revisions, confirm a unique
prefix, establish the dedicated project repo under ADR-005, publish/register it
through the authorized path, and sync its source records. Retain a pointer from
the Custodian rather than two editable copies of the programme.

Select a **small, useful software service or library capability** with a
repeatable independent test, a known release path and a second consuming repo.
Prefer an existing internal workload and existing CI. Avoid beginning with
identity, credential or production-control code as the agent's pilot target.
HelixForge owns the demand/contract; the actual source and consumer owners
accept the bounded implementation records. Record why this capability matters
and the expected reuse before selecting a convenient task from the queue.

Confirm one internal tenant, exact actor/project/repository/profile tuple,
human acceptance and operating owners, allowed branch/push/release effects,
the proposed G0–G5 targets, capacity allocation and an enforceable spend/time
envelope. Assess the outstanding NK-WP-0033/0034 verification incident against
the proposed privilege path; require applicable closure or an explicit scoped
owner disposition before expanding it.

Done when G0 is accepted in a source-backed decision, the project and concrete
pilot work are registered, and a future operator can determine who may run,
review and release it without reconstructing this assessment. Recording a
proposal does not grant execution or spending rights.

## T02 — Make the selected backlog actionable

```task
id: HFACT-WP-0001-T02
status: wait
priority: high
assignee: the-custodian
depends_on: [HFACT-WP-0001-T01]
blocking_reason: "Await project adoption and selection of the pilot dependency chain in T01."
```

Dependency: T01. Coordinator: the-custodian with source/projection owners.
Estimated effort: 1 engineering day, plus genuinely necessary projection fixes.

Use the 94-plan/264-task baseline as the dated starting point. Review the four
retired open identities, seventeen terminal human flags, terminal-parent tasks
and the unmatched local KG-WP-0005 through their existing owning paths. Do not
bulk-delete history or set statuses to improve a dashboard total.
Existing CUST-IN-0017 owns the thirteen Custodian historical consistency
failures and prefix conflict; reuse it rather than duplicate its triage.

For the pilot chain, ensure every waiting task has a supplying task/record,
accountable contact, precise return evidence, actual next action and review
condition; set human-needed only for real human dependencies. Capture published
source revision and freshness. Check projections without making the retiring
State Hub a new permanent owner. Refer off-path cleanup to existing owners;
it does not hold up the factory after its own records are trustworthy.

Adopt a factory WIP limit of one integrated delivery item plus two prerequisite
closures, with a named incident exception. Any wider portfolio reprioritization
remains a recommendation until owners accept it.

Done when the selected chain has complete actionable dependencies, a short
prepared human queue and a repeatable next-pick view; retired/terminal evidence
is excluded from current demand without losing residual ownership.

## T03 — Accept the existing identity, audit, approval and credential chain

```task
id: HFACT-WP-0001-T03
status: wait
priority: high
assignee: the-custodian
depends_on: [HFACT-WP-0001-T01]
blocking_reason: "Await T01 adoption; live returns are owed by KEY-WP-0013-T02, AUDIT-WP-0009-T09, APPROVAL-WP-0002 and SECRETS-WP-0009-T03."
```

Dependency: T01. Existing coordinator: GLAS-WP-0015. Supplying owners:
KEY-WP-0013-T02, AUDIT-WP-0009-T09, APPROVAL-WP-0002-T01/T03/T05,
SECRETS-WP-0009-T03 and exact linked custody/authorization records.
Rough shared effort with T04: 4–8 engineering days plus owner waiting.

Consume the existing seven-owner handoff packet. Identify the exact custody
record for both service clients and the audit sender; first-provision authority
cannot depend on the unprovisioned service. Keep the accepted tenant spelling
and proved policy/digest behavior pinned. Distinguish service-only admission
from a human callback requirement with owner evidence, not assumption.

Accept the real identity/custody, audit admission, deployed approval claim and
consume, and native credential delivery receipts from the owners. Evidence must
include successful binding and relevant wrong-tenant/scope, denied/reused action
and out-of-scope read rejection, plus revocation/expiry and non-secret audit
references. An image digest or a delivered message alone closes no live gate.

Done when native credential delivery for the exact proof tuple is verified
through the current owner contracts, with no bypass and no outstanding startup
prerequisite. Record later audit freshness/detection obligations separately;
admission success is not a completeness or tamper-evidence claim.

## T04 — Accept the real profile and prepare its Railiance placement

```task
id: HFACT-WP-0001-T04
status: wait
priority: high
assignee: the-custodian
depends_on: [HFACT-WP-0001-T01]
blocking_reason: "Await T01 adoption for preparation; the real-model portion also requires T03 native credential acceptance."
```

Dependency: T01; real model execution also requires T03. Supplying owners:
SAND-WP-0015-T04, GLAS-WP-0012-T02–T06 and concrete Railiance admission owners.

Accept protected installation of the already pinned runtime candidate and its
owner configuration. Reuse the existing real-rein acceptance contract: exact
profile/actor/project, provider path, model-created artifact, declared effects,
denial, cleanup and rollback to the retained blocked selection on failure.
Review changed pins as a new compatibility set. Do not re-prove resolved
candidate startup unless the artifact, environment or contract changed.

Then define the production-specific railiance01 placement, runtime owner,
profile/grant, credential path, service restart behavior and recovery inventory.
Start from the evidenced host user-service worker. Satisfy the owning
Railiance rail/rapp/reef admission contract; if the current host service needs
an ownership/admission record, create it in that owner rather than assuming
Kubernetes packaging is the production process. A localhost-only profile needs
explicit target-specific acceptance.

Done when G1 passes, the local result has acknowledged owner receipts, and the
Railiance configuration is concrete and admissible for T05. G2 is not closed
by this task's local proof.

## T05 — Close the current worker and queue loop on Railiance

```task
id: HFACT-WP-0001-T05
status: wait
priority: high
assignee: the-custodian
depends_on: [HFACT-WP-0001-T02, HFACT-WP-0001-T03, HFACT-WP-0001-T04]
blocking_reason: "Await actionable admission records, owner credential chain and accepted profile/placement from T02-T04."
```

Dependencies: T02–T04. Supplying work: REINAH-WP-0003-T05/T06,
ACTIVITY-WP-0032-T05, ACTIVITY-WP-0035-T08, ACTIVITY-WP-0036-T04.
Estimated effort: 2–3 engineering days excluding upstream changes.

Join the admitted task to the existing ActivityDefinition / ops_run intake and
current versioned profile/repository-grant contract. If a small intake adapter
is missing, record it in the proper owner and implement only that bounded gap;
the retired workplan launch endpoint is not a shortcut. Keep the definition
disabled until the owner's live readiness gates are accepted.

Accept the deployed pin and a natural claim → immediate heartbeat → execution
→ accepted terminal close trace. Require a controlled late-close/lease-loss
negative case, correct changed paths and commit ancestry, external metrics,
clean source state and sandbox teardown. Exercise the current durable close
outbox without duplicate mutation. A healthy API poll is not an executed task.

Done when G2 passes under the exact Railiance artifact/configuration and the
Activity Core, rein and Glas owners accept the same run evidence. Return it to
their existing tasks rather than leaving source-complete/live-wait tails open.

## T06 — Deliver and reuse a useful capability through the existing release path

```task
id: HFACT-WP-0001-T06
status: wait
priority: high
assignee: the-custodian
depends_on: [HFACT-WP-0001-T05]
blocking_reason: "Await the current governed Railiance worker proof in T05."
```

Dependency: T05; capability and owning implementation records selected in T01.
Acceptance: HelixForge product owner, source/consumer maintainers and workload
operator. Estimated effort: 3–5 engineering days.

Drive the selected human demand through capability intent, contract and relevant
OAS structural/semantic validation. The bounded agent change must satisfy an
independent predeclared test oracle and normal maintainer review. Record reuse
search and why an existing capability is extended or a new one is justified.

Use the source repo's current Forgejo workflow, or adopt the existing
railiance-enablement template where needed. Join source commit, CI evidence,
artifact digest/package version and release configuration revision. Apply only
the separately authorized release through the actual workload owner. Validate
the service behavior on Railiance and exercise the agreed rollback. Have the
second repo consume/reuse the capability and retain its acceptance evidence.

Done when G3 passes and the evidence chain links demand → contract → task/run
→ accepted change → CI → immutable artifact → authorized release → operational
result → reuse. Update the durable HelixForge capability/operating entry. A
generated document, empty commit or deterministic smoke alone is insufficient.

## T07 — Establish recoverable, measurable operation

```task
id: HFACT-WP-0001-T07
status: wait
priority: high
assignee: the-custodian
depends_on: [HFACT-WP-0001-T01]
blocking_reason: "Await T01 adoption for design; final live recovery proof requires the deployed T05/T06 configuration."
```

Dependency: T01 for design; T05/T06 for final deployed proof. Supplying owners:
REINAH-WP-0003-T05, the selected workload/package/reef owner and applicable
RPF-WP-0038-T04 recovery/custody coverage. Estimated effort: 2–3 engineering days.

Consolidate existing receipts for timeout/spend enforcement, worker death,
lease conflict, pending terminal-close replay, credential failure and sandbox
cleanup. Use disposable work and the current deployed configuration. Include
proof that a queue/Hub outage cannot produce duplicate accepted changes and
that restarting restores the right pending evidence. Bind backups and recovery
inventory to the actual host service, forge/artifacts and pilot workload.

Record per attempt queue wait, execution time, accepted/rejected result,
retries, failure class, human handling, model cost, relevant infrastructure cost
and release result. Include refused/admitted failures in denominators. Use
existing evidence and cost owners; start with a small generated scorecard if
automated aggregation is absent. Monitoring must distinguish a stale receipt
from a healthy current worker and alert the responsible operator through an
already authorized channel.

Done when G4 passes, rollback/recovery is executable by the named owner, costs
are bounded, and the measurement process can sustain G5 without reconstructing
individual agent sessions. Required audit claims are either freshly proved or
accurately degraded; unresolved detection work retains live owner records.

## T08 — Accept repeated delivery, transfer ownership and retire the project

```task
id: HFACT-WP-0001-T08
status: wait
priority: high
assignee: the-custodian
depends_on: [HFACT-WP-0001-T06, HFACT-WP-0001-T07]
blocking_reason: "Await useful delivery and operational controls from T06/T07, then the complete fourteen-day observation window."
```

Dependencies: T06 and T07. Reviewers: HelixForge acceptance owner, Railiance
operating owner and the-custodian. Effort: 1–2 engineering days for review and
handoff plus fourteen calendar days of observation.

Run the accepted fourteen-day G5 window. Admit at least five useful changes
across two repositories and preserve all attempts, costs, failure/repair events
and human time. If a target is missed, classify the limiting defect, create or
update its owner work record, and repeat the affected acceptance window after
correction. Do not redefine the metrics retrospectively to mark the project done.

Publish the operating runbook and capability/contract references in permanent
homes, including correction of HelixForge's stale Inter-Hub/nested State Hub
orientation where relevant. Hand the measured factory evidence to the company
project's UPC-WP-0003 acceptance context without claiming its longer window or
commercial goals complete. Additional tenants, model families, HA or unattended
release receive new benefit/authority decisions, not automatic activation.

Done when G0–G5 are accepted, durable owners acknowledge handoff, all actionable
residuals are live records, and the completion record lists owning repos,
merged/published revisions, deployment/rollback evidence and residual IDs.
Only then finish this workplan, synchronize it and archive the project as
read-only provenance. Participant services continue under their owners.