target-revenue/specs/TargetRevenueFrameworkCore.md

Target Revenue Framework — Core (Normative Extract)

Document version: TRF-Core-0.1 Status: Normative extract, Stage 0 Extracted from: specs/TargetRevenueLicenseConcept.md §7–§10, §18, §22 (concept draft remains the source; this document freezes day-to-day terminology per workplans/TREV-WP-0003-normative-core-extraction.md) Authority: This is the day-to-day normative reference for terminology, formulas, lifecycle, and rules. It does not invent meaning beyond the concept document — where the two ever appear to diverge, the concept document governs and this extract must be corrected, not reinterpreted. Working defaults: Several fields below are marked Stage 0 working default — provisional per specs/OpenQuestions-WorkingDefaults.md, not yet promoted to permanent norm. Everything else in this document reflects concept §24 open questions that remain genuinely open; this extract does not resolve them by omission.

---

1. Minimal core terminology

Seven core terms plus the Target Multiple and Trust Service/Extension boundary concepts. No other document may define these terms with variant meaning (PRD §6.1).

1.1 Phase

A bounded development undertaking governed by one Initial Target, one Milestone Release, one degeneration policy, and one Future License declaration.

A Phase may cover a bug fix, a refactoring, a performance improvement, a new feature, a new integration, a product-defining capability, or a platform-level improvement.

1.2 Milestone Release

The precisely identified software release that becomes available under the Future License when the Conversion Event occurs. Identifiable through an immutable release artifact, source revision, cryptographic digest, or equivalent reproducible reference.

1.3 Initial Target

The immutable monetary target declared for the Phase. A historical statement of the intended development monetization opportunity — it must not be silently increased or rewritten after the Phase has begun.

1.4 Target Multiple

A multiplier applied to the estimated development cost to determine the Initial Target. Represents a product and commercial hypothesis, not an objectively measurable claim.

Class	Multiple	Indicative interpretation
Commons	0x	Immediate permissive release or no development monetization target
Recovery	1x	Direct development cost recovery
Incremental	10x	Material enhancement of an existing use case
Product-defining	100x	Significant commercial differentiator or new product capability
Platform-defining	1000x	New platform, market, ecosystem, or foundational capability

Stage 0 working default (Q4): these classes are guidance, not a closed enum — target_multiple is an open non-negative decimal. Validators may warn (not fail) on values outside {0,1,10,100,1000}.

1.5 Development Credit

The portion of a collected and settled payment explicitly allocated toward satisfying the Initial Target of a specific Phase. An accounting concept of the framework — not synonymous with total revenue, recognized accounting revenue, cash flow, profit, or contribution margin.

1.6 Remission Credit

A transparent, non-revenue reduction of the Outstanding Target generated under the published degeneration policy. Records the expiry or reduction of the remaining commercial protection opportunity; must never be represented as revenue captured.

1.7 Outstanding Target

The remaining amount required for conversion:

Outstanding Target = max(0, Initial Target − Development Credit − Remission Credit)

1.8 Conversion Event

The moment the Outstanding Target reaches zero. The Milestone Release automatically and irrevocably becomes available under the declared Future License.

1.9 Future License

The permissive open-source license applying to the Milestone Release after the Conversion Event. Initial candidates: MIT (simplicity, broad compatibility) or Apache License 2.0 (explicit patent grant).

Stage 0 working default (Q3): future_license is closed to {MIT, Apache-2.0} for Stage 0 schema validation. Phase authors choose one at publication.

1.10 Trust Service

The publication, accounting, metrics, evidence, and attestation infrastructure for the framework. Observes, records, calculates, and attests — must not possess discretionary power to prevent a conversion that has occurred under the license.

1.11 Monetization Profile or Extension

A standardized or project-specific declaration describing what value is supplied, how it is priced, how payments are allocated, when allocations are recognized, how reversals are handled, and what evidence is required. May not redefine the core meaning of Phase, Initial Target, Development Credit, Remission Credit, Outstanding Target, Conversion Event, or Future License — this closed list, not "any term in this section," is the constitutional boundary (concept §7.11 verbatim; Milestone Release, Target Multiple, Trust Service, and this term itself are deliberately not on it).

---

2. Target determination

Estimated Development Cost = Estimated Effort × Published Rate + Approved Direct Costs
Initial Target             = Estimated Development Cost × Target Multiple

Example:

Estimated effort:          1 day
Published daily rate:      $1,000
Approved direct costs:     $0
Target Multiple:           100x
Initial Target:            $100,000

The estimate and multiple should be published before Development Credits are accepted. The Initial Target may be reduced through Remission Credits; it should not be retroactively rewritten, to preserve the historical product hypothesis and audit trail.

Stage 0 working default (Q5): target-basis transparency fields are estimated_effort_days, daily_rate, approved_direct_costs. Marketing, general overhead, unrelated R&D, opportunity cost, and speculative market-value uplifts not expressed via the Target Multiple are excluded from the Stage 0 basis by default.

---

3. Core lifecycle (five verbs)

Define

Publish the Phase, Milestone Release, Initial Target, Future License, degeneration policy, and applicable monetization extensions.

Allocate

Classify each payment and allocate it between target-relevant and non-target purposes.

Credit

Recognize the eligible target-relevant allocation as Development Credit for one identified Phase.

Remit

Generate Remission Credit according to the published degeneration policy.

Convert

Automatically apply the Future License to the Milestone Release when the Outstanding Target reaches zero.

stateDiagram-v2
    [*] --> Defined
    Defined --> Active: Phase published
    Active --> Active: Development Credit
    Active --> Active: Remission Credit
    Active --> Converted: Outstanding Target = 0
    Converted --> [*]

---

4. Core rules

The normative kernel is limited to rules that are universal, interoperability-critical, and trust-critical (governance test in §6 below).

Rule 1 — Immutable phase definition

The Phase, Milestone Release, Initial Target, Target Multiple, Future License, and applicable degeneration policy must be published before Development Credits are accepted. Subsequent changes must be versioned, historically visible, and constrained by the framework. The Initial Target may not be increased for commercial convenience after the Phase begins.

Rule 2 — Explicit allocation

No payment creates Development Credit unless its development allocation is explicitly defined.

Rule 3 — No duplicate credit

The same economic value may not be credited more than once, whether against one Phase or several Phases.

Rule 4 — Settled-payment recognition

Development Credit normally arises only from collected and settled payments. Refunds, chargebacks, and equivalent reversals must generate compensating ledger entries.

Rule 5 — Separate remission

Target degeneration must be recorded as Remission Credit and never misrepresented as captured revenue.

Rule 6 — Automatic conversion

When the Outstanding Target reaches zero, conversion occurs automatically and irrevocably without requiring further discretionary action by the licensor or Trust Service.

Rule 7 — Permanent prior freedom

Rights granted to an earlier Milestone Release may not be withdrawn or restricted by a later Phase.

Rule 8 — Correction without erasure

Published ledger history should be append-only. Errors and reversals should be corrected through compensating entries rather than deletion or silent modification.

Rule 9 — Conversion irreversibility

Once a valid Conversion Event has occurred, later refunds, accounting corrections, service failures, or disputes must not revoke the Future License grant.

---

5. Conversion — legal-technical requirements

The legal mechanism must establish that:

1. the Conversion Event is objectively determined by the Phase Manifest, ledger, and degeneration policy;
2. conversion occurs automatically when the Outstanding Target reaches zero;
3. no declaration by the licensor or Trust Service is required for legal effect;
4. the Future License grant is irrevocable;
5. the Milestone Release remains permanently available under the Future License;
6. later Phases may govern later improvements but may not restrict the converted release;
7. later accounting reversals do not restore the prior restriction.

Full Conversion Attestation field requirements and publication mechanics belong to specs/TargetLedgerSpecification.md and specs/TechnicalSpecificationDocument.md §3.5, not this core document — this section states only the legal-technical requirements the mechanism must satisfy, not the attestation schema.

---

6. Governance: what belongs in the core

A rule enters this core document only when it passes three tests (concept §20.1):

• Universal: nearly every Phase needs it.
• Interoperable: different implementations would otherwise produce incompatible meanings.
• Trust-critical: its absence would permit manipulation of the conversion bargain.

Otherwise, it belongs in a canonical profile (specs/CanonicalMonetizationProfiles.md, planned), an extension (specs/MonetizationExtensionSpecification.md), implementation guidance, or project policy — not here.

---

7. Foundational invariants

1. Every Phase has one identifiable Milestone Release.
2. Every Phase has one immutable Initial Target.
3. Every target-affecting movement is either Development Credit, Remission Credit, or an explicit correction or reversal.
4. No payment contributes without an explicit allocation rule.
5. The same value cannot be credited twice.
6. Operations monetization remains independent by default.
7. Degeneration is visible and is never represented as earned revenue.
8. Conversion is automatic, objective, and irrevocable.
9. The Trust Service supplies evidence, not discretionary permission.
10. Earlier permissive rights cannot be withdrawn by later Phases.
11. Extensions may add commercial models but cannot redefine the core.
12. Centralized operation must not prevent independent future verification or federation.

---

8. Open questions not resolved by this extract

Concept §24 lists fifteen open design questions. This extract resolves none of them by silent omission — where a Stage 0 working default exists (specs/OpenQuestions-WorkingDefaults.md), it is cited explicitly above (§1.4, §1.9, §2); everything else remains open and must not be treated as decided because it is absent from this document.