the-custodian/docs/proposals/prj-helixforge-factory/GOAL.md

repo	repo_flavor	project_status	started	reviewed
prj-helixforge-factory	project	draft	2026-09-08	2026-09-08

Goal

Outcome

Establish an internal HelixForge software factory that repeatedly turns bounded Coulomb demands into validated, reusable capabilities, with agent execution and at least one resulting software service running on Railiance. Humans retain capability acceptance and the release decisions required by existing policy.

The first factory serves one explicitly admitted internal tenant. A second repository demonstrates reuse; it does not introduce a second tenant. The existing Glas proof's tenant:platform, actor: agt, project: glas-local-proof remain scoped to that proof. The pilot gets its own reviewed binding where needed; no identity or authorization transfers merely by copying a profile.

Invariants

1. Source files and their published revisions own work. Existing owners retain code, deployment and policy authority. The project links their records.
2. An admitted task states capability intent, scope, tests, allowed repository effects, actor/tenant, runtime/profile pins, timeout, spend envelope and review disposition before execution. Repo instructions/prompts cannot expand grants.
3. Repository-changing agents execute inside the demonstrated isolation and repository transaction boundary. The first pilot permits one active mutator.
4. Source tests, deployed operation and accepted usefulness are separate claims. A local stub, startup probe or historical profile does not prove the current production route. The localhost proof is not Railiance admission.
5. Credential custody, policy decisions, approval consumption, audit delivery and publication use existing admitted owner paths. No secret material goes into Git, messages or progress evidence.
6. Build/test workers and release authority remain separated by their existing credential and trust boundaries. An accepted commit grants no implicit push, package publication or deployment authority.
7. Preserve working coordination and recovery services during migrations. Source deletion, public exposure changes and broader tenant admission retain their existing independent gates.
8. No new permanent service or generic framework is established in this project or in the retiring State Hub. Product implementations remain with owners.

Success gates

Targets below are proposed for T01 acceptance; they are not measured baselines or spending approval. Any revision must be decided before its observation window.

Gate	Required evidence
G0 — A bounded operating contract	Named capability acceptance owner, operational owner, internal tenant, pilot service, two participating repos, exact grants, budget, allowed release lane, test oracle and source-backed owner dependencies. All pilot dependencies have an owner, return evidence and next review/action.
G1 — Real governed model execution	Current GLAS-WP-0012 candidate produces its real artifact with protected owner credentials, correct attribution, declared egress, denial and teardown proof. Only the demonstrated profile becomes ready.
G2 — Railiance execution	Admitted installed runtime and worker on railiance01 execute through Activity Core with a current versioned profile and repository grant. Natural claim/heartbeat/close, accepted changed paths, clean source baseline, durable evidence/replay and controlled lease-loss refusal are demonstrated.
G3 — Useful delivered capability	One bounded real service/library change has intent and contract, relevant OAS structural/semantic checks, independent tests, accepted review, immutable Forgejo artifact identity, authorized Railiance release, service smoke and rollback proof. A second repo consumes or reuses the capability. Documentation-only or smoke-only output is insufficient for this gate.
G4 — Controlled operation	Budget/timeout and grant violations stop work; worker crash, Hub/queue outage, terminal-close replay and sandbox cleanup are exercised without duplicate accepted mutations. Backup and recovery evidence covers the actual worker state, source/artifact path and pilot workload. No stale evidence claim is presented as current.
G5 — Repeatability and founder load	Over 14 consecutive calendar days, at least five useful accepted changes across two repos, at least one service release, ≥80% of admitted delivery attempts accepted without operator repair, median human handling ≤30 minutes per accepted change, routine operation ≤30 minutes/day. All attempts, retries, rejects, costs and interventions retained. Report setup and attended security/recovery time separately and in total founder load.

Suggested initial hard limits for T01: one mutating run; 30 minutes wall clock per run; EUR 5 equivalent maximum model spend per run; EUR 25 equivalent per day and EUR 150 total pilot model spend. The admitted provider/runtime must be able to enforce the selected envelope; token counts alone do not establish a currency cap. If enforcement is unavailable, adopt and prove an enforceable conservative limit before admitting paid execution. Infrastructure costs are measured separately; adding capacity requires an owner decision.

G5 counts one admitted capability-change request as one delivery attempt; retries consume the same attempt's cost and handling time and must not inflate the denominator. Cancellation/refusal after admission remains an unsuccessful attempt with a reason. A human's planned review/release approval is expected; manual repair, re-prompting to rescue output, or bypassing a failed gate prevents that attempt from counting as accepted without repair. Five clean trivial runs cannot stand in for five useful changes with predeclared acceptance criteria.

Project retirement

Archive only when G0–G5 have accepted evidence, the permanent owners have accepted operating responsibility, and every actionable residual has a live owner record outside the closing narrative. Update HelixForge's durable capability/operating documentation and owning repos' runbooks; retain links to merged/published revisions, deployment evidence, decisions and residual IDs in a completion record. Do not archive or shut down any participating service as part of retiring this coordination repository.

External tenant onboarding, autonomous production release, additional rein/model families, full HA and commercial-company success are outside these gates. UPC-WP-0003 retains its separate ≥30-day company-load objective.