coulomb/target-revenue
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add info-tech-canon as first dry-run pilot candidate, exercise onboarding routine

Browse source 
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.
This commit is contained in:
tegwick 2026-07-29 23:15:42 +02:00
parent a29d781d92
commit b0f61b2d8b
7 changed files with 122 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

55
specs/PilotPhaseCandidateSurvey.md
View file

@ -128,6 +128,45 @@ 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 |
@ -136,14 +175,16 @@ that broader roadmap information.
| `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 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.
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