target-revenue/specs/PilotPhaseCandidateSurvey.md

Pilot Phase Candidate Survey

Status: Draft v0.1 Date: 2026-07-29 Workplan: workplans/TREV-WP-0008-governance-and-pilot-rollout.md T02 Feeds: workplans/TREV-WP-0008-governance-and-pilot-rollout.md T03 (draft pilot Phase Manifests) Primary artifacts: specs/TargetRevenueFrameworkCore.md §1.4 (Target Multiple)

Surveys coulomb-loop, net-kingdom, helix-forge, and the railiance-* family for one plausible first Milestone Release candidate per product line — a bounded, recently- or soon-to-be-completed piece of work with a defensible Target Multiple classification, not an arbitrary pick. The state hub's get_repo_goals returned no data for coulomb-loop, net-kingdom, or helix-forge at survey time, so this relied on direct repo inspection (README/SCOPE.md, git log, workplans/) instead, per the task's own fallback instruction.

This is a candidate survey, not a Phase declaration. Nothing here authorizes any real Phase — that remains gated behind T05.

---

1. coulomb-loop — no defensible candidate found

One-liner: "Customer engagement repository for Coulomb fleet self-improvement loops — contracts, rosters, and activity definitions; not agent runtime" (SCOPE.md). Its own scope explicitly excludes "application code for Coulomb products" — this repo organizes how other repos get worked on, it does not itself contain a product.

Recent activity: workplan-first agent guidance, instruction regeneration from state-hub templates, .repo-classification.yaml setup — all internal coordination tooling, not customer-facing capability.

Recommendation: no candidate. Forcing a pick here would violate the task's own "not an arbitrary pick" instruction — this repo is infrastructure for how work happens, not a governed software capability a Customer would pay for. Revisit if coulomb-loop's scope changes, or treat product Phases for Coulomb-managed products as living in those products' own repos rather than here.

2. net-kingdom — candidate: Local Identity (NK-WP-0002)

One-liner: "Platform domain for NetKingdom identity and security services" (SCOPE.md) — a real product domain, unlike coulomb-loop.

Candidate: NK-WP-0002 — "Local Identity: Bootstrap User Store & Minimal OIDC" (finished 2026-03-05). A zero-dependency, file-based user management capability deriving the primary user from the Linux identity, auto-generating test users, and (Stage 3) providing a minimal native OIDC provider for dev/test use — a standalone, bounded capability a Kubernetes deployment without a running Keycloak/full IAM stack yet could adopt independently.

Passed over:

• NK-WP-0001 (Keycloak SSO/MFA Platform) — status DEFERRED, superseded by NK-WP-0003 (KeyCape + Authelia + LLDAP). Not a clean "finished" candidate; the stack it targeted is no longer the deployed one.
• NET-WP-0020 (OpenBao unseal custody models), NK-WP-0021 (activity-core ops/Temporal UI least-privilege SSO) — both finished and real, but both are operational hardening of NetKingdom's own infrastructure (secrets custody, internal operator access control), not a bounded capability an external Customer would license. These are exactly the kind of "internal-infra, necessary but not product-shaped" work the task's Target Multiple guidance is meant to screen out.
• NK-WP-0022/NK-WP-0023 (railiance01 identity cutover, user-engine portal integration) — currently active, not yet a "finished" candidate.

Indicative Target Multiple classification: Incremental (10x) — NK-WP-0002 is a material, standalone enhancement (bootstrap identity without a full IAM stack dependency) rather than a net-new platform (1000x) or mere cost recovery (1x); it is a real, reusable capability, not a from-scratch new market (100x-class "product-defining" would overstate a bootstrap utility component).

3. helix-forge — no candidate; explicitly pre-product

One-liner: "HelixForge defines a capability-first development ecosystem for turning human intent into governed, reusable software capabilities" — but its own SCOPE.md states plainly: "It is not yet an application implementation."

Recommendation: no candidate, and this is not a survey gap — the repo itself says it is not yet at the implementation stage a Milestone Release requires. Revisit once HelixForge produces an actual implemented capability, not its current intent/architecture/vocabulary artifacts.

4. railiance-* family — candidate: vergabe-teilnahme (railiance-apps / RAILIANCE-WP-0002)

Surveyed all ten repos (railiance-apps, -bootstrap [not found under this exact name at survey time], -cluster, -enablement, -fabric, -forge, -hosts, -infra, -master, -platform).

Candidate: RAILIANCE-WP-0002 (railiance-apps, finished 2026-05-19, refreshed by RAILIANCE-WP-0014 finished 2026-07-11) — deployed vergabe-teilnahme, a Django application supporting participation in German public-sector procurement ("Vergabe") processes, to production at https://vergabe-teilnahme.whywhynot.de, with its own PostgreSQL database, container registry image, HTTPS/cert-manager TLS, and an operator runbook.

Why this is the strongest candidate across the whole family: it is the only deliverable found across all ten repos that is genuinely product-shaped — a discrete, customer-facing application a business that participates in public tenders could plausibly license or subscribe to. Everything else surveyed is internal infrastructure necessary to keep the Railiance stack itself running:

Repo	What was found	Why passed over
railiance-cluster	Kubernetes substrate (k3s, Helm, ingress, CNI), most recently a Knative serving install	Infra plumbing, not customer-facing
railiance-enablement	CI/CD templates, SDKs, buildpacks	Internal developer tooling
railiance-fabric	Ecosystem graph/registry modeling repo-family relations	Internal ontology/graph plumbing
railiance-forge	Forgejo/Gitea, registries, Actions runners	Internal build/artifact infra
railiance-hosts	Legacy Terraform/Ansible server provisioning, being retired in favor of railiance-infra	Superseded internal infra
railiance-infra	Canonical infra substrate (successor to -hosts); recent finished work is a Forgejo production migration	Internal ops
railiance-master	Repo taxonomy, cross-repo ADRs — architecture home, not even code-shaped	Organizational restructuring, not software
railiance-platform	Shared platform services (Postgres HA, cache, secrets, identity, object storage); recent finished work is a secrets-management extraction boundary	Internal platform plumbing

Indicative Target Multiple classification: Product-defining (100x) — vergabe-teilnahme is a real, market-facing application serving a specific commercial use case (public-tender participation management), not merely cost recovery or an incremental internal enhancement; whether it in fact represents a new platform (1000x) depends on ambitions beyond this survey's scope (e.g., whether it becomes a multi-tenant SaaS offering vs. a single-deployment tool) — 100x is the defensible default absent that broader roadmap information.

---

5. Summary table for T03

Product line	Candidate	Status	Indicative Target Multiple
coulomb-loop	None	—	—
net-kingdom	NK-WP-0002 Local Identity	Finished 2026-03-05	Incremental (10x)
helix-forge	None (pre-product)	—	—
railiance-*	vergabe-teilnahme (RAILIANCE-WP-0002/-0014)	Finished 2026-05-19 / refreshed 2026-07-11	Product-defining (100x)

Two of four product lines (net-kingdom, railiance-*) have a defensible candidate; two (coulomb-loop, helix-forge) do not, for principled reasons stated above, not because the survey was shallow. T03's draft, non-binding worked Phase Manifest examples should be built from the two real candidates — inventing manifests for the other two would misrepresent repos that are not yet at a stage this framework applies to.

6. Non-goals

• Declaring any real Phase — gated behind T05 regardless of what this survey finds.
• Selecting a Target Multiple value with legal or financial finality — the classifications above are indicative, per specs/TargetRevenueFrameworkCore.md §1.4's own framing ("a product and commercial hypothesis, not an objectively measurable claim").
• Re-surveying coulomb-loop/helix-forge on a schedule — revisit opportunistically when either repo's own scope changes, not on a fixed cadence this document sets.