tegwick
9886742fa8
T01: specs/TRSL-Governance.md. Resolves the Licensor-identity question (maintainer decision, 2026-07-29): a single shared Licensor, Binky Hedgehog GmbH, operating as the binky tenant, across all four product lines - not per-product-line. Unblocks (does not itself resolve) the License/CUA arbitral-institution selection now that the Licensor's own jurisdiction is known. Tables versioning/extension-governance/operator- governance status per concept §20, naming open items (compatibility rules, deprecation criteria, conflict-of-interest rule, key-rotation history) rather than silently assuming them solved. T02: specs/PilotPhaseCandidateSurvey.md. Direct repo inspection (hub had no goal data for three of four product lines) plus an Explore-agent survey of all ten railiance-* repos. Two defensible candidates found: NK-WP-0002 Local Identity (net-kingdom, Incremental 10x) and vergabe-teilnahme (railiance-apps, Product-defining 100x, the only genuinely product-shaped deliverable across ten railiance-* repos). coulomb-loop and helix-forge have no candidate, for stated principled reasons (internal tooling; pre-implementation-stage, respectively). T03: examples/pilot-candidates/ - draft, non-binding Phase Manifests for both real candidates, trsl:phase:draft-* ids, empty ledgers, schema-validated, explicit README stating nothing here is authorized to go live. T04: specs/TRSL-ContributorLicenseAgreement-Draft.md, implementing the CLA-not-assignment recommendation from history/260729-TRSL-ContributorRights-Research.md - narrowly scoped to the current Phase's TRSL terms plus its already-declared Future License at Conversion, same preliminary-candidate treatment as the License/CUA V1C1 documents. CONTRIBUTING.md updated to point at it while keeping the external-contribution block in effect until accepted. T05's precondition list updated to reflect what's now resolved, still left todo by design pending the maintainer's own go-live decision.
143 lines
11 KiB
Markdown
143 lines
11 KiB
Markdown
# 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.
|