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 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.
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.
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>
Per reviewer request (polish only, item 5): added the same "ultimate
source / day-to-day reference" dual-citation to the PRD header's
Terminology alignment line, matching README/TSD/CONTRIBUTING. Named all
three other normative extracts (PhaseManifestSpecification.md,
TargetLedgerSpecification.md, MonetizationExtensionSpecification.md) in
CONTRIBUTING.md's Terminology section, which previously named only
TargetRevenueFrameworkCore.md - now symmetric with README's full
four-document table.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
WP-0003-T06 review finding: §1.11 paraphrased concept §7.11's closed
extension-redefinition list (Phase, Initial Target, Development Credit,
Remission Credit, Outstanding Target, Conversion Event, Future License) as
"any term in this section" - silently broadening the constitutional
boundary to also cover Milestone Release, Target Multiple, Trust Service,
and Monetization Profile/Extension itself. This created an inconsistency
with MonetizationExtensionSpecification.md §3, which already carried the
concept's narrower list correctly, and would have left the extract and its
sibling document silently disagreeing on what an extension may not touch.
Corrected §1.11 to quote the closed list verbatim, matching the concept,
MonetizationExtensionSpecification.md, TSD §5, and PRD FR-4 (all four of
which already had it right). Whether the broader rule might be desirable
is a separate design question from this faithfulness fix, and is not
addressed here.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Found while preparing WP-0003-T06 for review: §5's prose still named the
unsplit administrative-correction type (renamed to
administrative-correction-development/-remission earlier this session) and
incorrectly implied both admin-correction types require a reverses
pointer, when only credit-reversal and remission-correction do.
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>
Revises V1C1 §7.4 per maintainer instruction: the License no longer sets a
named-by-default disclosure rule for published breach/termination records.
Instead, whether a Commercial Entitlement holder is named is governed
exclusively by the applicable Commercial Use Agreement — a bilaterally
negotiated contract where informed consent can actually be obtained. The
License itself only guarantees an anonymized Phase-and-category fallback
where no Commercial Use Agreement addresses it or none exists (e.g. a
noncommercial Section 2(c) breach).
This meaningfully reduces the License text's own legal exposure: the open
item is no longer "should the License name parties by default" but
"the not-yet-drafted Commercial Use Agreement template needs its own
naming/consent/data-protection clause" — recommended as a future
TRSL-CommercialUseAgreement-Draft.md deliverable, analogous to the CLA
recommendation already on record.
Updates Appendix A item 10, OpenQuestions-WorkingDefaults.md Q12 item 5,
PRD FR-10, and TSD §4.1 to match.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Per maintainer request after reviewing V1C1: breaches and their resolution
are transparently published via the Trust Service, giving the ecosystem a
conformity signal and creating reputational pressure toward compliance
alongside the existing commercial remedies.
- V1C1 §7.4 (new): Trust Service publishes the Licensor's breach notices,
cure status, and termination determinations per Phase, distinguishing
"alleged" from "determined" — a ministerial recording act, not a new
discretionary authority (consistent with §5.4's evidence-not-cause
principle). Named-by-default disclosure is the intended mechanism (the
deterrent only works if the party is identifiable), flagged in Appendix A
item 10 as the single most legally sensitive addition in this candidate:
it touches Commercial Use Agreement confidentiality, defamation law, and
data-protection law where the affected party is an individual.
- TSD §4.1: new Breach/Compliance Record Trust Service component, noted as
license-driven and deferred to a future Trust Service PRD rather than
retrofitted into WP-0002's already-finished Stage 0 scope.
- OpenQuestions-WorkingDefaults.md Q12: records the adopted default (publish
alleged/determined breach status) and the still-open naming-policy question.
- PRD FR-10: cross-references the new public record without resolving the
naming question.
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>
Resolves the WP-0003-T06 review flag: the single administrative-correction
ledger entry type had an unstated fold-side effect (concept §17 names the
type but never says which side of the target it corrects). Maintainer chose
option (a) — split into administrative-correction-development and
administrative-correction-remission so the corrected side is explicit in
the type name rather than an implicit library default.
- schemas/ledger_entry.schema.json: enum split, no other behavior change.
- src/target_revenue/fold.py: each new type maps to its named side only.
- specs/TargetLedgerSpecification.md, TechnicalSpecificationDocument.md
§3.2, ProductRequirementsDocument.md FR-5: updated to the split types.
- tests/test_ledger_fold.py: dedicated coverage for both new types plus a
regression test that the old unsplit type name is now rejected.
spec/TargetRevenueLicenseConcept.md §17 is left unedited — its entry-type
list is explicitly non-exhaustive ("may include"), so this specializes
rather than contradicts it.
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>
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.
Establishes specs/ProductRequirementsDocument.md and
specs/TechnicalSpecificationDocument.md, plus two workplans: prior-art
research for the TargetRevenueSourceLicense draft, and bootstrapping the
Trust Service reference implementation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
