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.