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.

---

4a. info-tech-canon — added 2026-07-29, maintainer-selected first repo

Outside this survey's original four product lines, the maintainer selected info-tech-canon directly as the actual first repo to build up the practical Phase-declaration routine on — confirmed explicitly as a dry run, not a go-live decision (examples/pilot-candidates/README.md).

One-liner: "Building interoperable, adaptable, and extensible information-processing systems" — InfoTechCanon: a markdown-first canon of standards/models plus a real, running service surface (CLI, importable Python service functions, a local JSON/HTTP API) built on top of it.

Candidate: the cumulative service surface across all twelve finished workplans (ITC-WP-0001 through ITC-WP-0012, all status: finished, most recently ITC-WP-0012 "Canonical Repository Layout Standard Integration," commit f7ad73d) — the kernel, service surface (CLI + JSON + local HTTP API), validation/indexing, a worked "small SaaS" profile proof, and consumer-facing review-kit/alignment tooling, all already used by at least one other repo in this ecosystem (ITC-WP-0008 explicitly supports railiance-fabric conformance).

Notable complication, flagged rather than smoothed over: this repo's current LICENSE is already MIT-0 — fully permissive today. A real Phase declaration for this repo (unlike net-kingdom/railiance-apps, which are not currently under any delayed-open-source license) would require replacing an already-open license with the restricted pre-conversion TRSL terms, not merely adding a monetization layer to a previously-closed codebase. That is a materially different, and more visible, change than the other two candidates involve — one more reason the maintainer's dry-run-only choice here is the right call before any real T05 decision.

Indicative Target Multiple classification: Product-defining (100x) — a real, differentiated, reusable standards-and-service capability that other repos already depend on, not mere cost recovery or an incremental tweak; not classified 1000x ("platform-defining") absent evidence it constitutes a new platform/market/ecosystem beyond its current consumer base.

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)
info-tech-canon	Service surface (ITC-WP-0001–0012)	All finished, latest 2026-06-13	Product-defining (100x)

Two of the original 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. info-tech-canon was added afterward as the maintainer's own choice for the first practical dry run, not part of the original four-product-line survey. T03's draft, non-binding worked Phase Manifest examples should be built from real candidates only — inventing manifests for repos not yet at a stage this framework applies to would misrepresent them.

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.