target-revenue/examples/pilot-candidates/README.md
tegwick b0f61b2d8b Add info-tech-canon as first dry-run pilot candidate, exercise onboarding routine
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.
2026-07-29 23:15:42 +02:00

2.3 KiB
Raw Blame History

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.id uses a draft- 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-0001ITC-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.