target-revenue/specs/TRSL-Governance.md

# TRSL/TRF Governance

Status: Draft v0.1
Date: 2026-07-29
Workplan: `workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T01
Primary artifacts: `specs/TargetRevenueLicenseConcept.md` §20, `specs/MonetizationExtensionSpecification.md` §4, `specs/CanonicalizationReviewChecklist.md`, `docs/adr/ADR-0002-hosted-trust-service-stack.md`

Implements concept §20's four governance principles (complexity budget,
versioning, extension governance, operator governance) as concrete,
operative rules for this framework's actual current state — a single
hosted Trust Service instance, one resolved Licensor, and four candidate
product lines — rather than restating §20 in the abstract.

---

## 1. Licensor identity — resolved

**Decision (maintainer, 2026-07-29):** there is a single Licensor across
all Phases declared under this framework for the foreseeable future:
**Binky Hedgehog GmbH**, operating as the **`binky` tenant** in the
`licensors` table (`migrations/0001_registries.sql`) and across the
`coulomb` Forgejo org's product lines (`coulomb-loop`, `net-kingdom`,
`helix-forge`, the `railiance-*` family).

**Consequences of this choice, made explicit rather than left implicit:**

- One Licensor API token (or a small, rotatable set under the same
  `licensor_id`) covers all four product lines' Phase registrations and
  Ledger appends — there is no per-product-line Licensor isolation at the
  Trust Service level; isolation between *Phases* (`TS-FR-8`) still holds,
  but not between *product lines*, since they share one Licensor identity.
- Commercial and legal exposure across all four product lines' Phases
  nominally attaches to the same legal entity. A dispute, breach
  determination (`specs/TargetRevenueSourceLicense-V1C1.md` §7.4), or
  Enforcement Action (`specs/EnforcementNetworkConcept.md`) on one
  product line's Phase does not legally implicate the others, but it is
  the same counterparty's record across all of them — a reputational and
  administrative fact worth naming, not a legal one this document
  resolves.
- **Now unblocked, not yet decided:** knowing the Licensor entity's own
  jurisdiction (Germany, GmbH) is exactly the missing input
  `history/260729-TRSL-Jurisdiction-Synthesis.md` §2 flagged before the
  arbitral institution and substantive governing law in License §11.1 /
  CUA §18 could be filled in from a template blank to an actual value.
  This document does not make that selection — it is a distinct, focused
  decision for whoever owns the License/CUA templates next, now that the
  blocking unknown (Licensor identity) is resolved.
- If this decision changes later (e.g., a product line spins out under
  its own entity), each Phase already declared under `binky` remains
  governed by `binky` as its Licensor of record — Phase Manifests are
  immutable (TSD §3.1), so a Licensor change is prospective only, never
  retroactive.

## 2. Complexity budget (concept §20.1)

Applied as-is: a proposed addition to the normative core
(`specs/TargetRevenueFrameworkCore.md`, `specs/PhaseManifestSpecification.md`,
`specs/TargetLedgerSpecification.md`, `specs/MonetizationExtensionSpecification.md`)
must pass all three tests — universal, interoperable, trust-critical — or
it belongs in a canonical profile
(`specs/CanonicalMonetizationProfiles.md`), a degeneration policy
(`specs/TargetDegenerationPolicyResearch.md`), an implementation detail
(`docs/adr/`), or a project-specific policy (a single Phase's own Manifest
fields), never the shared core. This is not new policy — WP-0003's own
review process already applied it (e.g., the §1.11 fix rejecting a
broadened core-term-redefinition list) — this section names it as a
standing rule rather than an ad hoc practice.

## 3. Versioning (concept §20.2)

Already implemented, not merely planned, across every layer §20.2 names:

| Layer | Versioning mechanism | Where |
|---|---|---|
| TRSL legal text | `Version 1, Candidate <n>` in the document header | `specs/TargetRevenueSourceLicense-V1C1.md` |
| Framework core | Dated normative extracts, sourced from the concept doc | `specs/TargetRevenueFrameworkCore.md` et al. |
| Phase Manifest schema | `framework`/`license` semver-like tags in the manifest itself | `schemas/phase_manifest.schema.json` |
| Degeneration policies | `trsl:policy:<slug>@<version>` URN | e.g. `trsl:policy:linear-longstop-v0@1.0` |
| Monetization extensions | `trsl:extension:<slug>@<version>` URN | `schemas/extension_contract.schema.json` |
| Trust Service protocol | This repository's own commit history + `docs/adr/` decisions | `docs/adr/ADR-0001`, `ADR-0002` |

**Rule, stated explicitly for the first time here:** a Phase remains
governed by the exact versions it declared at registration
(`phase.framework`, `phase.license`, `phase.degeneration_policy`,
`phase.extensions[]`) unless an explicit, recorded migration is accepted
for that specific Phase — never a silent, framework-wide reinterpretation
that changes an already-registered Phase's terms out from under it.

## 4. Extension governance (concept §20.3)

| §20.3 item | Status |
|---|---|
| Registration criteria | `specs/MonetizationExtensionSpecification.md` §3 (conformance rule) + `src/target_revenue/validation.py` — implemented and tested |
| Canonicalization criteria | `specs/CanonicalizationReviewChecklist.md` (WP-0007-T04) — implemented as a checklist, not yet exercised against any real profile |
| Conformance tests | `tests/test_extension_conformance.py`, `tests/test_hosted_conformance.py` — implemented |
| Compatibility rules | **Not yet defined.** No document yet states what happens when a `canonical` extension's own contract needs a breaking change (new major version vs. deprecate-and-replace). Flagged as an open item, §6 below. |
| Deprecation rules | **Partially defined.** `status: deprecated` exists in the schema and is described in §4 of the extension spec ("no longer recommended; existing registrations remain valid evidence") but no document describes *who* may deprecate an extension or under what criteria — same gap pattern as canonicalization had before WP-0007-T04. Flagged, §6. |
| Conflict-of-interest rules | **Not yet defined.** With a single Licensor (§1) reviewing its own extensions for canonicalization, the reviewer and the reviewed party's interests are not separated by default. Flagged, §6. |
| Dispute procedures | Partially covered by `specs/TargetRevenueSourceLicense-V1C1.md` §7 (breach/cure/termination) and `specs/TargetRevenueCommercialUseAgreement-V1C1.md` §9 (breach disclosure), but no procedure exists yet for a dispute *about an extension's canonicalization or deprecation* specifically, as distinct from a dispute about a Phase's own Commercial Use. Flagged, §6. |

## 5. Operator governance (concept §20.4)

For the single hosted Trust Service instance
(`workplans/TREV-WP-0006-trust-service-implementation.md`, deployed per
`docs/adr/ADR-0002-hosted-trust-service-stack.md` on `railiance-cluster`):

| §20.4 disclosure | Current answer |
|---|---|
| Operator identity | Binky Hedgehog GmbH (`binky` tenant) — same entity as the Licensor (§1); this framework does not currently distinguish "who operates the Trust Service" from "who is the Licensor," since both are the same party at this stage |
| Applicable terms | This repository's specs (`specs/TargetRevenueLicenseConcept.md` and its extracts) govern the framework; no separate Trust-Service-specific terms of service exist yet — flagged, §6 |
| Signing keys | `TRF_SIGNING_KEY_HEX` env var, Ed25519, exposed publicly and unauthenticated via `GET /public-key` (`service/app.py`) so any party can verify a signature independent of trusting the operator's access control (`docs/adr/ADR-0002-hosted-trust-service-stack.md`) |
| Key-rotation history | **Not yet tracked.** No mechanism exists yet to publish a history of past signing keys if the current one is ever rotated — a verifier who only has the current public key cannot verify historical entries signed under a prior key. Flagged, §6. |
| Service continuity policy | Single-instance, single-server (ADR-0002's explicitly named risk: "single HostEurope server is a single point of failure... acceptable for alpha/beta pilot scale... must be revisited before any external or higher-availability commitment") |
| Archival and export policy | Every Phase's full evidence package (Manifest, Ledger, Attestation) is exportable via public `GET` endpoints at any time (`specs/TrustServiceProductRequirementsDocument.md` §6) — no separate scheduled-archival process exists beyond "export is always available," which is adequate for offline verifiability (TSD §5) but not a substitute for an operator-side backup/disaster-recovery policy, which is an infrastructure concern for `railiance-cluster`, not this repository |
| Correction and dispute processes | Ledger corrections: `credit-reversal`/`remission-correction`/`administrative-correction-*` entry types (append-only, TSD §3.2). Broader disputes: License §7 / CUA §9. No Trust-Service-specific "I think this record is wrong" process beyond those ledger-level correction types exists yet |
| Framework change process | This repository's own workplan/ADR/human-accept-gate process (`CONTRIBUTING.md`), which is itself the framework change process — there is no separate, more formal process distinct from how this repository already operates |

## 6. Explicitly open items (not resolved by this document)

Naming these here — rather than letting them stay implicit — is this
document's actual contribution beyond restating what already exists:

1. **Extension compatibility/deprecation criteria** (§4): who may deprecate
   a canonical extension, and what counts as a breaking vs. non-breaking
   change to one.
2. **Conflict-of-interest rule for canonicalization** (§4): with one
   Licensor currently reviewing its own extensions, some explicit
   acknowledgment or safeguard is warranted before canonicalization
   becomes routine — even if the safeguard is initially as simple as
   "canonicalization decisions are recorded publicly with named
   attribution" (already true per `CanonicalizationReviewChecklist.md`
   item 8) rather than a heavier external-review requirement.
3. **Extension/canonicalization-specific dispute procedure**, distinct
   from the License/CUA's Commercial-Use-focused dispute provisions.
4. **Signing-key rotation history publication** (§5): no mechanism yet for
   a verifier to check a signature made under a since-rotated key.
5. **A Trust-Service-specific terms-of-service document**, separate from
   the framework specs themselves.

None of these block `workplans/TREV-WP-0008-governance-and-pilot-rollout.md`
T02–T04 (repo survey, draft pilot manifests, CLA draft) — they are named
so that T05's go-live gate can weigh them explicitly rather than discover
them as an afterthought once real Phases are already running.