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.