Maintainer (Bernd) accepted 2026-07-30: estimated_effort_days/daily_rate
driven directly by commit-clustered human interaction time;
approved_direct_costs from real metered AI token cost
(get_token_summary); workplan/task-volume and file/line-size metrics
serve only as a sanity check on the human-time estimate, never their
own dollar figure; Target Multiple remains a human classification.
Candidate B recorded as the considered, not-adopted alternative.
The two deliverables have independent formula/rights decisions and
implementation arcs; keeping them in one workplan blurred that they
can be reviewed and sequenced separately, even though the Control
Plane's Phase-registration flow is expected to consume the
Calculator's output once both exist.
WP-0009 (Target Revenue Control Plane): keeps the original workstream
ID, retitled and re-tasked to 3 focused tasks - rights-model decision
(human gate), backend auth/audit layer, interactive UI flows.
WP-0010 (Development Effort Calculator, new): 3 tasks - formula
decision (human gate), implementation, application to the real
candidate repos already identified in WP-0008. No real Phase
declaration in either workplan's scope.
Updated both concept documents' workplan cross-references and
README.md's summary table accordingly.
specs/TargetRevenueControlPlaneConcept.md: an interactive UI over the
hosted Trust Service for the binky tenant, prioritizing interactive
Development Credit entry creation. Flags the actual new design gap
WP-0006 didn't need to solve: one Licensor token vs. multiple human
users needing individually attributable actions - recommends the
Control Plane hold the Licensor token server-side and layer its own
human-user auth/audit log in front, rather than requiring a WP-0006
auth schema change, while leaving the choice to a human gate (T02).
specs/DevelopmentEffortCalculatorConcept.md: turns four metric
families (human interaction time via commit-clustering, workplan/task
volume, file/line complexity, AI token cost via the state hub's
get_token_summary) into target_basis values feeding the framework's
own existing Initial Target formula - not a new formula. Presents two
combination strategies (labor-cost-anchored vs. composite-index) as
alternatives for a human gate (T01) rather than picking one.
workplans/TREV-WP-0009-control-plane-and-effort-calculator.md: 5 tasks
(two human-gated formula/rights decisions, two implementation tasks,
one task to apply the calculator to the real candidate repos already
identified in WP-0008). Explicitly does not declare any real Phase -
both deliverables feed WP-0008-T05's own gate, they don't bypass it.
Maintainer decision, 2026-07-29/30: adopts TRSL V1C1 as the preliminary
governing LICENSE across every repo in the coulomb Forgejo org,
confirmed explicitly as "every repo, no exceptions" including
target-revenue itself and internal tooling repos. This is a
license-text adoption, not a Phase declaration - no Initial Target,
Trust Service registration, or Development Credit tracking exists for
any repo as a result. WP-0008-T05 (real Phase go-live) remains todo
and unaccepted.
Applies TRSL to this repo's own LICENSE (self-referential wording,
since target-revenue is the canonical source) and updates
pyproject.toml's license field from MIT-0 to TRSL-0.1.
history/260730-TRSL-OrgWideLicenseRollout.md is the full execution
record: ~90 repos adopted successfully, 2 committed locally only (no
git remote configured: executor-sandbox, executor-worker), and one
explicitly flagged exception (the-custodian - carried a pre-existing
proprietary/confidential license, deliberately not touched pending
separate confirmation, not silently folded into the blanket
instruction).
scripts/rollout/LICENSE.trsl-v1c1 is the deployed template used across
all repos (operative legal text only, points back to this repo's
specs/TargetRevenueSourceLicense-V1C1.md for the full candidate-status
banner and Appendix A rather than duplicating it ~90 times).
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.
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.
Maintainer (Bernd) accepted 2026-07-29: trsl:policy:linear-longstop-v0
is confirmed as the degeneration formula for the first pilot cohort,
per T01's recommendation - already implemented/tested, pilot-ready
today. progress-paused-longstop-v1 remains the named next iteration,
not required before WP-0008's pilot Phases proceed. Updates
OpenQuestions-WorkingDefaults.md Q7 from "working default" to
"Adopted 2026-07-29." All 4 WP-0007 tasks now done; workplan finished.
T01: specs/TargetDegenerationPolicyResearch.md. Survey finds no
precedent (BSL/FSL/Elastic) implements progress-sensitive degeneration
- TRSL's model is original design. Proposes a candidate v1 formula
(90-day rolling "quiet period" pause on Remission Credit accrual
during active Development Credit periods), resolves the
contributor-diversity input as explicitly not-adopted (no
gaming-resistant signal exists yet), and resolves the
longstop/progress-sensitivity relationship as a hard, unconditional
backstop. Does not recommend v0 vs v1 for T02 - that's the human gate.
T02: recommendation added (confirm v0 for the first pilot cohort, name
v1 as the next iteration) - left todo per the human-accept policy.
T03: specs/CanonicalMonetizationProfiles.md with worked narratives for
all six catalog profiles, plus two new fixtures (product-ideation,
general-consulting), both schema-validated and added to the
parametrized conformance test.
T04: specs/CanonicalizationReviewChecklist.md, an 8-item checklist
layered on the already-implemented promote_extension_canonical()
mechanism (WP-0006-T03) - defines what a reviewer must verify, not a
new promotion mechanism.
migrations/0004_breach_records.sql models a case's lifecycle as
append-only events (alleged/cured/determined/terminated) grouped by
case_id rather than one mutable row - resolution is always a new,
later event, never an edit. A CHECK constraint makes the
anonymized-default rule (License V1C1 §7.4) a database fact:
named_entitlement_holder can be set if and only if anonymized = false.
src/target_revenue/breach_record.py's publish_breach_event() enforces
per-Licensor phase ownership and rejects named-disclosure requests
that don't also set named_disclosure_authorized_under_cua: true - the
Trust Service records the Licensor's assertion that the CUA's naming
clause authorizes it, it never verifies the underlying CUA text
itself. Signs every event with the same instance Ed25519 key already
used for Ledger entries and Attestations.
Adds POST/GET /phases/{id}/breach-records. Guarded the .registry
import behind a lazy in-function import (matching attestation.py's
TYPE_CHECKING pattern) so tests/test_breach_record.py (7 tests) runs
under plain system Python with no psycopg dependency. 5 new
Docker-gated tests cover the default-anonymized lifecycle, the
named-disclosure authorization gate, cross-Licensor rejection,
signature verification, and DB-level UPDATE/DELETE rejection.
This closes WP-0006 again - all 9 tasks done.
Reopens WP-0006 (status: active) to track the gap T01's Trust Service
PRD flagged: the Breach/Compliance Record component (TSD §4.1, added
alongside License V1C1 §7.4) postdates WP-0002 and was never assigned
to T03-T08. Scopes it: publish alleged/determined breach status
without adjudicating, default anonymized with CUA-§9-gated named
disclosure, append-only per the existing pattern, reusing the
per-Licensor token model for writes.
tests/test_hosted_conformance.py (6 Docker-gated tests) addresses all
three requirements from the task description: the golden Phase example
(manifest + full ledger + all 4 extensions) replayed through the
hosted API reproduces exactly the offline-established outcome
(Development Credit 67000, Remission Credit 33000, Outstanding Target
0, MIT) including the hosted Attestation; two Phases under different
Licensors operate with interleaved appends and are proven isolated
both positively and negatively (cross-Licensor writes rejected); a
parametrized regression test across four ledger shapes (credits-only,
remission, reversal, admin corrections) confirms hosted-append-then-
offline-fold always matches expected totals.
WP-0006 is now finished - all 8 tasks (PRD, ADR-0002, registries,
ledger API, metrics, attestation, onboarding, conformance) done. T01's
flagged gap (no task owns hosting the Breach/Compliance Record
component from License V1C1 §7.4) remains open and unassigned.
specs/TrustServiceOnboarding.md defines the mechanism: a Phase Manifest
file is committed to the declaring repo (durable, independently
foldable forever) and separately registered with the hosted service;
once registered, the Ledger's live authoritative copy is the hosted
service only, not a second competing file. Licensor token bootstrapping
is explicitly out of scope here (a WP-0008-T01 governance action).
scripts/trf_onboard.py: a dependency-light CLI (stdlib urllib +
target_revenue.validation only, no FastAPI/psycopg needed to onboard a
Phase) with validate/register-phase/append-entry/status subcommands.
The Licensor token is read only from a named environment variable,
never accepted as a literal argument.
tests/test_trf_onboard.py (4 tests, no network/Docker) proves
invalid-manifest and missing-token-env cases fail before any HTTP
attempt, by monkeypatching the request function to raise if called.
tests/test_onboarding_hosted.py (1 Docker-gated test) runs an actual
uvicorn server on a real socket and drives the full
register -> append -> status round trip through the CLI as an external
repo would invoke it.
migrations/0003_attestations.sql: one row per Phase, no UPDATE/DELETE
grant for trf_app (a published attestation is permanent).
src/target_revenue/attestation.py: publish_attestation() is idempotent
(existing row returned unchanged, never regenerated) and derives
conversion_timestamp from the ledger itself via _find_conversion_prefix(),
which finds the earliest prefix where the fold reaches Outstanding
Target = 0 rather than trusting entries[-1] or wall-clock publish time -
so a later unrelated entry can never change an already-converged Phase's
recorded conversion moment. Raises NotConvertedError rather than
fabricating a conversion. Reuses conversion.generate_attestation()
unchanged. Guarded the psycopg import behind TYPE_CHECKING so the pure
helper stays testable under plain system Python.
service/app.py adds GET /phases/{id}/attestation (unauthenticated,
publish-on-first-observation).
tests/test_attestation.py (3 tests, no Docker/Postgres) proves the
earliest-crossing behavior. 6 new Docker-gated tests in
test_ledger_hosting.py cover pre-conversion 404, the core
legal-technical property that /metrics facts/calculations/forecasts
are identical whether or not /attestation was ever called, one-time
publication, signature verification, and DB-level UPDATE/DELETE
rejection.
src/target_revenue/metrics.py: compute_metrics(manifest, entries, as_of)
is pure/deterministic like fold.py, reusing fold.py/conversion.py
unchanged. Returns facts/calculations/forecasts as three explicitly
separated blocks (TrustServicePRD TS-FR-5), covering the mandatory Q9
set plus the recommended velocity/forecast tier - forecasts are always
null rather than populated once a Phase has converted or velocity is
non-positive, so nothing disguises a projection as a fact.
Adds GET /phases/{id}/metrics (unauthenticated per FR-9/FR-10).
tests/test_metrics.py (6 tests) needs no Docker/Postgres and runs
under plain system Python. One new Docker-gated test in
test_ledger_hosting.py proves the hosted /metrics response exactly
matches compute_metrics() run offline against the same export.
migrations/0002_ledger.sql adds ledger_entries with an identity-column
sequence for exact append order and no UPDATE/DELETE grant for trf_app.
src/target_revenue/ledger.py: append_entry() rejects caller-supplied
previous_entry_hash/signature, enforces per-Licensor phase ownership,
serializes concurrent appends via pg_advisory_xact_lock, computes the
chain tip and signs with the Trust Service instance's own Ed25519 key
(service/keys.py), reusing validation.py's checks unchanged. Adds
POST/GET /phases/{id}/ledger and an unauthenticated GET /public-key.
Also fixes a route-ordering bug found while wiring this in: phase IDs
never needed the {phase_id:path} converter (they contain colons, not
slashes), and its greedy matching was swallowing /ledger-suffixed
paths into the plain GET /phases/{id} route.
tests/test_ledger_hosting.py (8 Docker-gated tests) exercises hash-chain
linkage, forged-field rejection, cross-Licensor isolation, currency and
duplicate-id rejection, DB-privilege enforcement, signature
verification via the public-key endpoint, and the task's own
highest-priority property: append -> export -> offline fold reproduces
the exact expected Development/Remission Credit and Outstanding Target.
Adds migrations/0001_registries.sql (licensors, phase_manifests,
extensions tables; trf_app role with no UPDATE/DELETE grant on either
table, canonicalization only via a SECURITY DEFINER function), and
src/target_revenue/registry.py + service/app.py: a thin FastAPI layer
wrapping the existing validation.py checks with persistence and
per-Licensor token auth, adding no new validation logic per ADR-0002.
New optional service/service-dev dependency groups keep the core
offline library dependency-free. tests/test_registry_hosting.py (7
tests, Docker-gated, auto-skip otherwise) spins an ephemeral disposable
Postgres container and verifies registration, rejection, duplicate/
unknown-token handling, extension canonicalization, and two explicit
database-privilege checks that the app role cannot bypass the
append-only/governance-gated guarantees.
Elaborates framework PRD FR-8/9/10 for a hosted, multi-tenant service:
stakeholders, which Stage 0 guarantees (WP-0002) carry over unchanged
vs. which single-Phase/no-auth/no-tenancy constraints must lift and
onto which task (T03-T08), functional/non-functional requirements, and
an API surface sketch. Flags that no current task owns hosting the
Breach/Compliance Record component added by License V1C1 SS7.4.
Maintainer decision (2026-07-29): full specialist legal review of the
TRSL/CUA is postponed until the framework moves out of beta, given
limited legal/commercial exposure during build/alpha. WP-0004-T10 and
WP-0005-T10 synthesize their jurisdiction research into adopted alpha/beta
working defaults (governing law -> arbitration at a neutral seat,
liability cap, data protection minimal-collection practice, and the
Enforcement Network's fee mechanics) rather than full resolution, and are
accepted on that basis. Propagates the decision to the License/CUA V1C1
Appendix A tables and status banners, SCOPE.md, CONTRIBUTING.md, the
WP-0008-T05 go-live gate, and README.md.
With WP-0001/0002/0003 finished, PRD Phase 4b (hosted Trust Service) is
unblocked per SCOPE.md's own sequencing rule, and the midterm goal shifts
from framework design to practical application: governing and monetizing
repos across the coulomb Forgejo org's product lines (coulomb-loop,
net-kingdom, helix-forge, the railiance-* family).
- TREV-WP-0006: Trust Service reference implementation (PRD Phase 4b).
Eight tasks from PRD to conformance-tested hosted service, explicit that
it builds infrastructure only - no real payments or Phase tracking.
- TREV-WP-0007: Degeneration policy finalization (PRD Phase 5) and the
full canonical monetization profile catalog (remainder of Phase 3) -
pilot Phases can't responsibly launch on the placeholder pilot policy
and one-line profile defaults alone.
- TREV-WP-0008: Governance formalization (PRD Phase 7) and pilot rollout
preparation. Forces a real design decision the framework never had to
answer while single-repo-hypothetical: who is "the Licensor" across four
independent product lines. Produces draft, non-binding Phase Manifests
as worked examples for one repo per product line, and a CLA draft.
All three explicitly preserve SCOPE.md's existing "no production Phases
until legal review" guardrail rather than overriding it under pressure to
monetize real repos: WP-0008-T05 is a dedicated, human-gated go-live
decision, and no other task in any of the three workplans is permitted to
authorize a real Phase, real Commercial Entitlement sale, or real
Development Credit tracking.
Updates SCOPE.md (new Stage 0/Stage 1 maturity table, revised out-of-scope
table distinguishing "infrastructure in scope" from "going live still
gated"), PRD roadmap (Phase 4b/5/7 now active, pointing at the new
workplans), and README's active-work table accordingly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bernd reviewed the License candidate and accepted it, conditioned on one
refinement to §1's "Commercial Use" definition: replaces the prior
circular definition ("use other than Noncommercial Use") with an
objective, billing-based trigger. Commercial Use now means billing a
customer for pre-conversion Software use, full stop - regardless of
whether the resulting payment is registered with the Trust Service.
Billing without recording the payment in the Target Ledger is Commercial
Use without a valid Commercial Entitlement, a Section 3 violation
addressed under Section 7 and, where applicable, the Enforcement Network.
This substantially resolves the affiliate/contractor/mixed-purpose/
public-sector ambiguity Appendix A item 1 flagged, since classification
no longer depends on who the customer is, only on whether they are
billed. A narrower residual item remains open: whether consumer-
protection law overrides this classification for an individual/sole-
proprietor customer in a given jurisdiction (the same recurring pattern
found across WP-0004's jurisdiction research).
Updates the document's status banner: condition 3 (human acceptance) is
now met; conditions 1 (specialist legal review) and 2 (full Appendix A
resolution) remain open - V1C1 is accepted as adequate briefing material
for counsel, not yet official Version 1.0. Marks WP-0001-T06 done and the
WP-0001 workplan finished (all 6 tasks complete). Updates
OpenQuestions-WorkingDefaults.md Q2, README, and CONTRIBUTING.md to match.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cross-cutting research (New York Convention enforceability, neutral-seat
arbitration practice, and a consolidated drafting principle) revises the
China finding from T06/TREN-T06: China has enforced the New York
Convention since 1986 (arbitral awards travel via a ~172-state regime
with limited refusal grounds) but has ratified no foreign-judgment
convention, relying on patchy bilateral treaties and evolving reciprocity
for court judgments specifically. Arbitration, not the litigation-focused
China rider previously recommended, is likely the more promising
enforceability path for a Chinese Customer - and for the Enforcement
Partner Agreement too, per a cross-reference added to
specs/EnforcementNetworkConcept.md.
Also produces a consolidated drafting principle: write clarity-sensitive
clauses to satisfy Germany's Transparenzgebot, UK's UCTA reasonableness,
and Australia's expanded Unfair Contract Terms regime simultaneously,
since research this program has already found separately shows none of
the three reduces to another.
Updates License Appendix A item 6 and CUA Appendix A item 1 accordingly.
WP-0004 now has 9 of 10 tasks done; only the human-gated T10 synthesis
remains.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Per maintainer correction: the previous "Standard Bounty Amount" was still
paid only on success, meaning it remained outcome-contingent and would not
actually escape prohibitions worded around outcome-contingency generally
(India's Rule 20: "a fee contingent on the results of litigation") rather
than percentage-proportionality specifically (Germany's quota-litis-style
rules). Renamed to "Standard Financing Amount" and restructured as a fixed
sum paid or made available regardless of the Enforcement Action's outcome
- a grant toward litigation cost, not a contingent fee in any form.
specs/EnforcementNetworkConcept.md §13 rewritten as a sequential rule
rather than "higher of two comparable numbers" (contingent percentages and
non-contingent financing are not commensurable, and treating them as
interchangeable is exactly what would make the financing look like a
disguised contingent fee):
1. 50% Contingency Share where lawful at that level.
2. Else the jurisdiction's own lower lawful outcome-contingent cap.
3. Else - no lawful outcome-contingent fee exists at all - no
Contingency Share; the Licensor's own non-contingent fee arrangement
with its lawyer governs what's owed win or lose, and the Trust
Service's Standard Financing Amount offsets that cost regardless of
outcome. Fee risk is genuinely higher here, by design: this is what
it means for the risk-shifting a contingent fee normally provides to
be unavailable, not an oversight to paper over.
New §13.0 makes explicit (per maintainer instruction) that nothing in this
rule creates a right for the Trust Service, an Enforcement Partner, or a
Litigation Funder to initiate a case - pressing charges remains
exclusively the Licensor's decision. The rule only makes a ready,
low-friction default (published caps, financing, EPA template) available
once that decision is made.
Added new core term §5.9 Standard Financing Amount; updated §5.5-5.7, §6's
lifecycle step, §9's EPA outline, and the concise definition to match.
Updated WP-0005 T10's synthesis scope and README accordingly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Per maintainer request, replaces the flat "working default 50%" Contingency
Share with a systematic per-jurisdiction rule, directly responding to
WP-0005's finding that 50% is unsafe almost everywhere except the UK:
1. 50% applies if lawful in the jurisdiction.
2. Otherwise, the higher of:
(A) the Jurisdiction Percentage Cap - the actual local statutory
maximum, published by the Enforcement Registry as background
information for prospective Enforcement Partners; or
(B) a Standard Bounty Amount - a fixed sum (not a percentage),
defaulting to $1,000 local-currency-equivalent, recalculated
annually to 50% of the trailing-18-month average unpaid-fees
amount where more than 10 settled cases exist (a sample-size floor
to avoid thin-sample noise), announced by 31 July, effective the
following 1 January, always capped at the specific case's own
unpaid fees.
Flags, as the highest-priority open question this rule itself introduces:
whether a fixed, non-percentage bounty actually escapes contingency-fee
prohibitions worded around outcome-contingency generally (India's Rule 20:
"contingent on the results of litigation") rather than percentage-
proportionality specifically (Germany's quota-litis-style rules) - the
Standard Bounty Amount may not solve what it was designed to solve in
exactly the jurisdictions that motivated it, and this is not yet verified.
Added as new specs/EnforcementNetworkConcept.md §13 (Concise Definition
renumbered §14; no other section numbers changed, so existing cross-
references to §5.5/§6/§8/§9/§11 from workplans and history/ artifacts
remain valid). Updated §5.5, §5.7, and §8's key findings to point to the
new rule. Folded the rule's population and open questions into
WP-0005-T10's synthesis scope.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Executes all remaining shared jurisdictions across both workplans:
Germany/EU (deepened contract-law angle), US (deepened), UK (deepened),
Argentina, India, China, Africa (South Africa + OHADA), and Asia-Pacific
(Singapore, Japan, Australia) - 13 new history/ research artifacts.
Highest-priority findings:
- Australia's Unfair Contract Terms regime (expanded Nov 2023) covers
standard-form contracts with any business under 100 employees/$10M
turnover by default - the CUA is exactly such a contract, and most
realistic Customers fall within this threshold. Unlike every other
jurisdiction's consumer carve-out, this is not an edge case.
- China requires a "foreign-related" contract even to select foreign
governing law, subject to a vague public-interest override even then -
confirms a dedicated China rider is needed for both the License/CUA and
the Enforcement Partner Agreement, not a shared global clause.
- India flatly prohibits advocate contingency fees (no exception gates,
stricter than Germany) while explicitly permitting third-party
litigation funding - the cleanest confirmation yet that the Litigation
Funder/Local Counsel split-role model is both necessary and legal there.
- Japan's Article 12 fee-splitting rule means even the split-role
fallback needs jurisdiction-specific structuring - the first case where
the workaround itself, not just the original mechanism, has an open
compliance question.
- Contingency Share ceilings vary widely where available: UK 50% (exact
match), South Africa 25%, Argentina 35% (50% only with risk assumption),
China 18% down to 6% on a sliding scale that shrinks as claims grow.
- Recurring cross-jurisdictional pattern (Germany, EU, US via CCPA,
Argentina): B2B governing-law/liability clauses are respected, but an
individual/sole-proprietor Customer's consumer-protection status is the
operative risk everywhere, not a one-off edge case.
Updates specs/EnforcementNetworkConcept.md §8.1 with a full 12-jurisdiction
findings table and three cross-cutting conclusions. Updates both V1C1
documents' Appendix A items (governing law, liability cap, data
protection) with the most consequential findings. Both workplans now have
only their human-gated synthesis tasks (T09-T10 / T10) remaining.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Introduces specs/EnforcementNetworkConcept.md: independent, locally-licensed
Enforcement Partners pursue unauthorized Commercial Use (License §3
violations) in their home jurisdiction for a Contingency Share of Recovery,
so enforcement scales the way the framework's monetization already does -
through aligned incentive rather than central litigation capacity. New
terminology (Alleged Violation, Enforcement Action, Recovery, Contingency
Share, Platform Share, Enforcement Registry, Enforcement Partner Agreement)
plus a proposed enforcement-recovery Monetization Extension so Recovery
flows into Development Credit through the existing accounting model rather
than a parallel bucket.
Flags the mechanism's central risk up front rather than assuming it away:
lawyer contingency fees are not legal everywhere. Backed by
workplans/TREV-WP-0005-enforcement-network-research.md (10 tasks); four
executed this session with live web research:
- Germany/EU: RVG §4a permits contingency fees only in three narrow gates,
none fitting this fact pattern well - single-role Enforcement Partner is
very likely not viable; France permits a fixed-fee-plus-uncapped-result-
fee structure instead; EU litigation-funding regulation is proposed
(2022 EP resolution) but not yet adopted.
- US: contingency fees broadly permitted; practical precondition is timely
copyright registration of the Milestone Release to unlock statutory
damages/fee-shifting; Copyright Claims Board flagged as a lower-cost venue.
- UK: Damages-Based Agreements cap fees at 50% for this case category -
the concept's originally-proposed 50% Contingency Share lands exactly on
this real statutory ceiling, the first jurisdiction where the figure is
precisely validated rather than arbitrary.
- Mechanism design: synthesizes the above into a single Enforcement Partner
Agreement template with jurisdiction-conditional role structure
(single-role vs. Litigation Funder/Local Counsel split), with a payment-
flow diagram showing the Development Credit allocation is unaffected by
which structure applies.
Six of ten WP-0005 tasks remain open (Argentina, India, China, Africa,
Asia-Pacific, and the human-gated synthesis). Cross-referenced from README.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Backs the License/Commercial Use Agreement V1C1 candidates with a research
plan covering Germany, the rest of the EU, the US, the UK, Argentina (Latin
America anchor), India, China, representative African jurisdictions,
representative Asia-Pacific jurisdictions beyond India/China, and a
cross-cutting global choice-of-law/choice-of-forum strategy task.
Ten tasks: T01-T08 one per jurisdiction/family, T09 the cross-cutting
choice-of-law mechanism ("wherever"), T10 a synthesis that proposes (but
does not itself apply, per the human-accept gate) resolutions for the
governing-law, liability-cap, indemnification, and data-protection Appendix
A items in both V1C1 documents. Deliberately scoped as multiple targeted
tasks rather than one generic "international law" task, since prior
research already showed enforceability norms diverge in ways that don't
compress into a single finding (German AGB law covers B2B, EU consumer law
doesn't).
This workplan is planning only — no research has been executed yet.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds specs/TargetRevenueCommercialUseAgreement-V1C1.md, the companion
agreement the License repeatedly refers to but never itself set terms
for: commercial entitlement grant, fees and explicit Development Credit
allocation, applicable monetization extensions, metering, audit rights,
term/termination (cross-referenced to License §7.2/§5.2 so a Commercial
Use Agreement termination can never revoke an already-converted Milestone
Release), and a real Section 9 implementing the informed-consent breach-
disclosure election that License §7.4 deferred here: opt-in named
disclosure vs. an anonymized default, a 10-business-day pre-publication
notice with a dispute window, and a data-protection carve-out.
Unlike the License, this Agreement had no dedicated prior-art research
pass (WP-0001 T01-T05 covered license models, terminology, patents,
contributor rights, and jurisdiction constraints, not commercial-agreement
drafting norms) — its preliminary notice says so explicitly, and Appendix A
leaves Section 13 (Indemnification) unwritten rather than guess at a
default carrying real financial exposure.
Corrects three prior references from the placeholder filename
"TRSL-CommercialUseAgreement-Draft.md" to the actual deliverable name, and
cross-references it from README, PRD, TSD, and SCOPE.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Persists the five prior-art/legal research artifacts and the original
draft skeleton as dated history/ records (260729- prefix, git mv to
preserve history), consistent with this repo's convention that history/
holds dated non-normative artifacts rather than living working documents:
- history/260729-TRSL-PriorArt-Survey.md
- history/260729-TRSL-Terminology-Guardrails.md
- history/260729-TRSL-FutureLicense-PatentPrecedent.md
- history/260729-TRSL-ContributorRights-Research.md
- history/260729-TRSL-Jurisdiction-StandardTerms.md
- history/260729-TargetRevenueSourceLicense-Draft.md (superseded)
Adds specs/TargetRevenueSourceLicense-V1C1.md: the first candidate written
as actual operative license text (11 sections: definitions, noncommercial
grant, commercial-use restriction, patent license, automatic conversion,
successive phases, termination/cure, warranty/liability, trademarks,
general provisions) rather than a bracket-annotated skeleton. Carries a
prominent preliminary-status notice near the top and a non-normative
Appendix A tracking the nine items still needing legal resolution before
any candidate can become official Version 1.0.
Updates all cross-references (README, PRD, TSD, SCOPE, workplan) to the
new paths; the workplan's T06 human-accept gate now points at V1C1.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Moves TargetRevenueLicenseConcept.md from the separate singular spec/
directory into specs/ (git mv, preserving history) and updates every live
cross-reference (README, CONTRIBUTING, all specs/*.md, workplans, schema
comments, source docstrings, test file) to the new path.
This resolves the spec/ vs specs/ split that history/260728-SWOT-Assessment.md
flagged as a "perpetual footgun" and recommended deciding on. The historical
record of that split and the recommendation itself are left unedited in
history/ (a dated assessment, not a living document) — only README and TSD
now document the merge as resolved, with a pointer back to that history file
for context.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Five research artifacts under specs/research/, grounded in primary-source
license text fetched live rather than relying on training-data recall:
- TRSL-PriorArt-Survey.md: BSL 1.1, FSL, PolyForm Noncommercial, Fair
Source, Elastic License 2.0. Confirms TRSL's closed {MIT, Apache-2.0}
Future License enum and no per-Phase custom license text follows FSL's
deliberate fix for BSL's "Additional Use Grant" variability problem.
- TRSL-Terminology-Guardrails.md: confirms via OSI OSD Clause 6 that
pre-conversion TRSL cannot be Open Source; confirms README's existing
guardrail table without change.
- TRSL-FutureLicense-PatentPrecedent.md: MIT has no patent language; Apache
2.0 has an explicit contribution-scoped grant + litigation termination.
Recommends TRSL's pre-conversion phase also carry an express patent grant.
- TRSL-ContributorRights-Research.md: confirms via DCO 1.1 text that a DCO
alone is insufficient for TRSL's dual-future-license promise; recommends
a narrowly-scoped CLA over copyright assignment.
- TRSL-Jurisdiction-StandardTerms.md: deepens German §31/§32 UrhG (primary-
confirmed) and §307 BGB Transparenzgebot (secondary-confirmed, flagged
for counsel verification); corrects scope re: EU UCTD 93/13/EEC being
consumer-only vs. German AGB law covering B2B too. Ranks five terms most
needing objective definitions.
specs/TargetRevenueSourceLicense-Draft.md (T06) synthesizes all five into a
non-binding skeleton with every clause tagged [CONFIRMED BY RESEARCH],
[LEGAL], [WORKING DEFAULT], or [OPEN]. Per the T06 human-accept gate, the
workplan task stays `todo` — ready for review, not accepted.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Stabilizes day-to-day terminology out of the exploratory concept draft:
- specs/TargetRevenueFrameworkCore.md — core terms, target formula,
five-verb lifecycle, nine rules, invariants.
- specs/PhaseManifestSpecification.md — field tiers aligned with
schemas/phase_manifest.schema.json.
- specs/TargetLedgerSpecification.md — entry types, hash chain, pure
Outstanding Target fold, aligned with the WP-0002 library.
- specs/MonetizationExtensionSpecification.md — six-field contract,
registered/canonical distinction, Stage 0 Q11 catalog.
Cross-links PRD/TSD/README/CONTRIBUTING to the new extracts, confirms no
placeholder tails remain, and prepares a review checklist for T06 (human
promotion gate, left open pending maintainer review).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Delivers the offline runnable specification foundation for the Trust Layer
(TSD §3-§6), not a hosted Trust Service:
- JSON Schemas for Phase Manifest, Ledger Entry, Extension Contract, and
Conversion Attestation, encoding the Stage 0 working defaults (Q3 future
license enum, Q6 single-currency Phases, Q8 required longstop_at).
- src/target_revenue: pure Outstanding Target fold, SHA-256 hash-chain
verification, Ed25519 signing helpers, extension conformance checks
(including a core-term-redefinition heuristic), and conversion detection
that never requires an attestation document to determine conversion status.
- examples/phase-001: golden Phase package matching the concept doc's
worked example, generated via scripts/generate_golden_phase.py so the
hash chain is computed by the library itself, not hand-typed.
- 32 passing pytest tests covering manifest/ledger/extension conformance,
tamper/reorder detection, and the full lifecycle fold to conversion.
- docs/adr/ADR-0001: proposed (not accepted) Stage 0 stack choice, per the
WP-0002-T01 human-accept gate — implementation proceeded against the
proposal as the workplan note permits, but the task stays open.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Introduce SCOPE, expanded README, CONTRIBUTING, and provisional open-question
defaults. Rescope Trust Service work to offline schemas/fold/fixtures, add
normative core extraction workplan, and split PRD roadmap Phase 4 into
foundation vs hosted service. Sync workplans with State Hub.
