tegwick
b0f61b2d8b
Maintainer chose info-tech-canon (outside the original four product lines) as the actual first repo to build up the practical Phase-declaration routine on, explicitly confirmed as a dry run, not a T05 go-live decision. Adds a third draft, non-binding manifest (examples/pilot-candidates/info-tech-canon-service-surface/): the cumulative service surface across ITC-WP-0001-0012 (all finished), Product-defining (100x). Flags a notable complication rather than smoothing it over: this repo's current LICENSE is already MIT-0, so a real Phase here would mean replacing an already-open license with restricted pre-conversion TRSL terms - a materially different step than the other two candidates. Exercised the full onboarding routine end-to-end against a real, ephemeral local instance of the hosted Trust Service (Docker Postgres, migrations applied, binky Licensor token seeded, uvicorn running the actual service/app.py): register-phase -> append-entry -> status all worked via scripts/trf_onboard.py exactly as specs/TrustServiceOnboarding.md describes, no code changes needed. Dry-run infrastructure torn down afterward; only the draft manifest files persist.
199 lines
11 KiB
Markdown
199 lines
11 KiB
Markdown
# 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.
|