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. |
||
|---|---|---|
| .. | ||
| info-tech-canon-service-surface | ||
| net-kingdom-local-identity | ||
| railiance-vergabe-teilnahme | ||
| README.md | ||
Pilot candidate Phase Manifests — DRAFT, NOT DECLARED
These manifests are draft, non-binding worked examples
(workplans/TREV-WP-0008-governance-and-pilot-rollout.md T03), following
the pattern established by examples/phase-001/. They are structurally
valid and conformance-tested exactly like examples/phase-001/, but:
- No Commercial Entitlement is for sale under either manifest.
- No Development Credit is being tracked for either candidate.
- Neither repo's actual License header has been changed to TRSL.
phase.iduses adraft-prefix specifically so it cannot be confused with a real, declared Phase.
Built from the two candidates identified with a defensible rationale in
specs/PilotPhaseCandidateSurvey.md (T02) — coulomb-loop and
helix-forge produced no defensible candidate at survey time and are
not represented here.
info-tech-canon (2026-07-29): the maintainer chose info-tech-canon
as the actual first repo to build up the practical Phase-declaration
routine on, explicitly as a dry run, not a go-live decision
(confirmed directly, not assumed) — see
specs/PilotPhaseCandidateSurvey.md §5 for the candidate rationale. This
repo was outside the original four product lines T02 surveyed; its
candidate was added afterward as this specific, real routine-building
exercise, not a T02 survey gap.
Nothing here is authorized to go live. That remains gated behind
workplans/TREV-WP-0008-governance-and-pilot-rollout.md T05, regardless
of how complete or plausible these examples look — including
info-tech-canon, which was explicitly confirmed as dry-run-only.
| Directory | Product line | Candidate deliverable | Indicative Target Multiple |
|---|---|---|---|
net-kingdom-local-identity/ |
net-kingdom |
NK-WP-0002 Local Identity |
Incremental (10x) |
railiance-vergabe-teilnahme/ |
railiance-* (railiance-apps) |
vergabe-teilnahme (RAILIANCE-WP-0002/-0014) |
Product-defining (100x) |
info-tech-canon-service-surface/ |
info-tech-canon |
Cumulative service surface, ITC-WP-0001–ITC-WP-0012 |
Product-defining (100x) |
All figures (initial_target, target_basis) are illustrative
placeholders for this worked-example exercise, not a real costing or
pricing proposal — see specs/PilotPhaseCandidateSurvey.md for the
underlying candidate rationale.