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.

README.md

@@ -80,7 +80,7 @@ The concept's §13 now defines a **Global Contingency Share Determination Rule**
 | [TREV-WP-0005](workplans/TREV-WP-0005-enforcement-network-research.md) | Enforcement Network legal feasibility research — **finished**, T10 synthesis accepted 2026-07-29 on the same alpha/beta basis (Japan's Article 12 risk remains explicitly unresolved) |
 | [TREV-WP-0006](workplans/TREV-WP-0006-trust-service-implementation.md) | Hosted Trust Service reference implementation (PRD Phase 4b) — **finished**, all 9 tasks done (Postgres-backed registries/ledger/metrics/attestation/breach-record, ADR-0002 accepted, onboarding CLI, hosted conformance suite) |
 | [TREV-WP-0007](workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md) | Degeneration policy + canonical monetization profile catalog — **finished**, all 4 tasks done. `trsl:policy:linear-longstop-v0` confirmed 2026-07-29 as the v1 norm for the first pilot cohort; `progress-paused-longstop-v1` named as the next iteration, not yet adopted |
-| [TREV-WP-0008](workplans/TREV-WP-0008-governance-and-pilot-rollout.md) | Governance formalization + pilot rollout across `coulomb-loop`/`net-kingdom`/`helix-forge`/`railiance-*` — active; T01 (Licensor: Binky Hedgehog GmbH), T02 (candidate survey), T03 (draft pilot manifests), T04 (CLA draft) done; T05 (go-live gate, human decision) remains `todo` by design |
+| [TREV-WP-0008](workplans/TREV-WP-0008-governance-and-pilot-rollout.md) | Governance formalization + pilot rollout across `coulomb-loop`/`net-kingdom`/`helix-forge`/`railiance-*` — active; T01 (Licensor: Binky Hedgehog GmbH), T02 (candidate survey), T03 (draft pilot manifests), T04 (CLA draft) done. `info-tech-canon` added 2026-07-29 as the maintainer's chosen first repo to build up the routine on (dry run only, confirmed) — full onboarding CLI round trip exercised end-to-end against a live local instance. T05 (go-live gate, human decision) remains `todo` by design |
 
 Hub index: [`WORK-RECORDS.md`](WORK-RECORDS.md) · brief: [`.custodian-brief.md`](.custodian-brief.md)
 

examples/pilot-candidates/README.md

@@ -16,14 +16,25 @@ Built from the two candidates identified with a defensible rationale in
 `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.
+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

examples/pilot-candidates/info-tech-canon-service-surface/ledger.json

@@ -0,0 +1 @@
+[]

examples/pilot-candidates/info-tech-canon-service-surface/manifest.json

@@ -0,0 +1,28 @@
+{
+  "framework": "TRF-0.1",
+  "license": "TRSL-0.1",
+  "phase": {
+    "id": "trsl:phase:draft-info-tech-canon-service-surface",
+    "milestone_release": {
+      "name": "info-tech-canon-service-surface-v1 (ITC-WP-0001..0012)",
+      "source_revision": "f7ad73d"
+    },
+    "initial_target": {
+      "amount": 2500000,
+      "currency": "EUR"
+    },
+    "target_basis": {
+      "estimated_effort_days": 25,
+      "daily_rate": 1000,
+      "approved_direct_costs": 0,
+      "target_multiple": 100
+    },
+    "future_license": "MIT",
+    "degeneration_policy": "trsl:policy:linear-longstop-v0@1.0",
+    "longstop_at": "2029-01-01T00:00:00Z",
+    "ledger": "examples/pilot-candidates/info-tech-canon-service-surface/ledger.json"
+  },
+  "extensions": [
+    "trsl:extension:development-license@1.0"
+  ]
+}

specs/PilotPhaseCandidateSurvey.md

@@ -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
+Two of the original four product lines (`net-kingdom`, `railiance-*`)
-defensible candidate; two (`coulomb-loop`, `helix-forge`) do not, for
+have a defensible candidate; two (`coulomb-loop`, `helix-forge`) do not,
-principled reasons stated above, not because the survey was shallow.
+for principled reasons stated above, not because the survey was shallow.
-T03's draft, non-binding worked Phase Manifest examples should be built
+`info-tech-canon` was added afterward as the maintainer's own choice for
-from the two real candidates — inventing manifests for the other two
+the first practical dry run, not part of the original four-product-line
-would misrepresent repos that are not yet at a stage this framework
+survey. T03's draft, non-binding worked Phase Manifest examples should be
-applies to.
+built from real candidates only — inventing manifests for repos not yet
+at a stage this framework applies to would misrepresent them.
 
 ## 6. Non-goals
 

tests/test_pilot_candidate_manifests.py

@@ -16,20 +16,21 @@ from target_revenue import validation
 PILOT_CANDIDATES_DIR = REPO_ROOT / "examples" / "pilot-candidates"
 
 
-@pytest.mark.parametrize(
+PILOT_CANDIDATE_NAMES = [
-    "name",
+    "net-kingdom-local-identity",
-    ["net-kingdom-local-identity", "railiance-vergabe-teilnahme"],
+    "railiance-vergabe-teilnahme",
-)
+    "info-tech-canon-service-surface",
+]
+
+
+@pytest.mark.parametrize("name", PILOT_CANDIDATE_NAMES)
 def test_pilot_candidate_manifest_is_conformant(name):
     manifest = json.loads((PILOT_CANDIDATES_DIR / name / "manifest.json").read_text())
     validation.validate_phase_manifest(manifest)
     assert manifest["phase"]["id"].startswith("trsl:phase:draft-")
 
 
-@pytest.mark.parametrize(
+@pytest.mark.parametrize("name", PILOT_CANDIDATE_NAMES)
-    "name",
-    ["net-kingdom-local-identity", "railiance-vergabe-teilnahme"],
-)
 def test_pilot_candidate_ledger_is_empty_draft_state(name):
     ledger = json.loads((PILOT_CANDIDATES_DIR / name / "ledger.json").read_text())
     assert ledger == [], "draft candidates must not carry any real ledger entries"

workplans/TREV-WP-0008-governance-and-pilot-rollout.md

@@ -154,6 +154,29 @@ Entitlement is for sale, no Development Credit is tracked, and neither
 repo's actual License header has changed — nothing here is authorized to
 go live regardless of how complete it looks (T05 still gates that).
 
+**Addendum, 2026-07-29:** the maintainer separately 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.** A third draft
+manifest, `examples/pilot-candidates/info-tech-canon-service-surface/`,
+was added (candidate: the cumulative service surface across
+`ITC-WP-0001`–`ITC-WP-0012`, all finished; Product-defining 100x;
+`specs/PilotPhaseCandidateSurvey.md` §4a). Notable complication surfaced
+and flagged rather than smoothed over: this repo's current `LICENSE` is
+already MIT-0 — a real Phase here would mean *replacing* an already-open
+license with restricted pre-conversion TRSL terms, a materially different
+and more visible step than the other two candidates. The full onboarding
+routine (`scripts/trf_onboard.py register-phase` → `append-entry` →
+`status`) was exercised end-to-end against a real, ephemeral local
+instance of the hosted Trust Service (Docker Postgres, migrations
+0001–0004 applied, `binky` Licensor token seeded, `uvicorn` running the
+actual `service/app.py`) — register, a 10,000 EUR illustrative
+development-credit entry, and a status check all worked exactly as
+`specs/TrustServiceOnboarding.md` describes, with no code changes needed.
+The dry-run Postgres container and service process were both torn down
+afterward; nothing from this exercise persists beyond the draft manifest
+files themselves.
+
 ## Contributor rights instrument (CLA)
 
 ```task