Modelling deal terms

1. What "Model these terms" does

A deal records what was offered and what was agreed as versioned term sets of typed terms. Once a term set is proposed or agreed, it is frozen: a draft cannot be modelled. "Model these terms" takes that frozen set and one of the asset's full-ownership scenarios, and maps the terms it can value onto that scenario's deal structure. The result is a new scenario (a partner case, not the asset's base case unless a user later sets it so) that pins the exact term-set version it followed. The source scenario is never changed. The mapping is a pure, versioned function: term-model mapping v4. Every term in the set gets an outcome (modelled or not modelled, with a reason), no term is ever dropped silently, and every approximation the mapping makes is returned as a named assumption shown beside the result.

2. What is modelled, and how

The mapping only values payments to your organisation and the license grant that constrains their territory. It cannot yet subtract a payment your organisation makes, so from mapping v4 a set in which your organisation pays an upfront, milestone or royalty on the modelled asset is refused (paid_terms_not_modelled, §4): valuing only what your organisation receives would overstate its side. Who bears development costs comes from an explicit cost-share term; the one fixed assumption, that a royalty-only model has the licensee bear them, is always named (section 7).

The deal-structure type the mapping writes follows the same three modes the wizard already uses: a profit share gives Profit split (with the tenant's cost share carried across); otherwise no cost share, or an explicit 0% tenant share, gives Royalty or license-out; a 100% tenant cost share gives Milestone and royalty. Every "Royalty or license-out" scenario carries the assumption that the licensee bears all development and launch costs, because the model treats that deal type as licensee-funded regardless of the modelled cost share.

3. What is not modelled, and why

A term the mapping cannot value is never dropped. It is listed as "not modelled" with one of the reasons below.

4. What is refused, with nothing written

Some conditions stop the action entirely rather than modelling around them. When one applies, no scenario is created and the term set is unchanged.

The conversion-rate refusal, P3-D7, applies verbatim: "Set a conversion rate for {currency} before modelling these terms." The mapping has no conversion-rate input yet, so this refusal currently blocks every term whose amount is not in USD; every upfront, milestone and royalty that would be modelled must be denominated in USD.

5. The territory restriction, and its approximations

A territory-limited royalty or profit share is modelled only against the scenario's geography entries that are inside its territory, never against worldwide revenue by default. The scenario's geography entries must each carry a recognised territory key; an entry with none makes the whole action refused rather than guessed. When the restriction applies, the kept geographies' peak revenue is scaled to their combined share of the scenario's total peak sales, and their individual shares are renormalised so they still sum to the whole. Rights retained outside the licensed territory are not part of the resulting scenario at all: they are not represented, priced or discounted anywhere in it.

This restriction is an approximation, not an exact re-derivation of a per-territory deal, and it names the approximations it makes:

• The US IRA price cap applies to US revenue only (model 4.0.0). If the United States sits outside the term's territory, the cap is dropped from the model; if it sits inside, the cap applies to the kept US geography (or to rest of world when no kept geography covers the US) and not to the other kept regions. Scenarios modelled on earlier models applied it to every kept region.
• When the source scenario uses the epidemiology builder, the modelled scenario fixes peak revenue at the builder's calculated result (scaled to the kept share) and turns the builder off, because the underlying calculation would otherwise recompute a worldwide peak from the builder's inputs on every recompute.
• When a royalty's territory is wider than its governing license grant's, the modelled revenue is restricted to the grant's narrower territory instead.

Each kept region keeps its own launch delay. From rNPV model 3.0.0, royalties, royalty tiers, sales milestones and the profit-split pro-forma follow each kept region's revenue share and launch, so a region that launches later than the lead market earns its modelled revenue later too. Term-model mapping v1 on model 2.9.0 timed all deal revenue from the lead launch; the Methodology M3 record of this section describes it.

6. Milestone timing, at the end of a development stage

A milestone is only modelled with a development-stage, regulatory-approval or first-commercial-sale trigger; every other trigger kind is not modelled (§3). A modelled milestone always lands at the end of a stage in the source scenario, never at an arbitrary date:

• A milestone triggered by the completion of a numbered phase lands at the end of the scenario's stage with that exact phase number.
• A milestone triggered by the start of a numbered phase lands at the end of the previous stage (a Phase 1 start lands at the end of the scenario's last preclinical stage, if it has one).
• Regulatory approval, first commercial sale, and a completed regulatory review all land at the end of the scenario's last stage. When that last stage is an actual NDA/BLA review stage, this is exact; when the scenario has no such stage, the last stage stands in for approval instead, and the mapping names this as an assumption. A regulatory-approval or first-sale milestone tied to a jurisdiction lands at that same point whatever its jurisdiction: the mapping does not time a US approval apart from an EU one, and names this as an assumption.

A milestone whose matching stage is not present in the source scenario is not modelled (stage_not_in_scenario), never guessed at a nearby stage.

7. Who bears development costs: set by the terms

The mapping never assumes which side of the deal pays for development after it closes. That treatment is set only by an explicit cost-share term, and the rules keep it representable by the model's existing deal structures:

• A profit share cannot be modelled without a cost-share term alongside it (the "add a cost-share term" refusal, §4): a profit split with no stated cost treatment is refused, not defaulted.
• Without a profit share, the tenant's cost share must be 0% or 100%; anything in between (a partial cost share) is refused, because the model cannot represent a partial cost share together with a royalty.
• A capped cost share is refused outright; the model needs a plain percentage share.
• At most one cost-share term can be modelled at a time.
• Whichever side of a deal pays a cost-share term bears that share of development costs; your organisation's share is the contract share when it pays, and one minus that share when it receives it.
• Every "Royalty or license-out" scenario (no profit share, tenant cost share 0% or none) still carries the assumption that the licensee bears all development and launch costs after the deal, because the model's royalty-only deal type is hard-coded that way, whatever cost share was modelled.

8. What a modelled scenario keeps locked, and what stays editable

A scenario modelled from deal terms follows those terms: the deal structure, the geography split and peak revenue, the epidemiology inputs, and whatever decides where a modelled milestone lands (the stage list and names, whether an NDA/BLA review stage exists, and the development-stage plan's work packages, stage labels and PoS gates) cannot be edited by hand on that scenario. Probability of success, costs, durations and every other input the terms did not set stay editable, including the PoS, costs and durations inside the development-stage plan. The application enforces this with a fixed message: "This scenario follows deal terms. Change the terms and model them again instead." To change the modelled economics, change the terms (a new term-set version) and model them again; modelling always creates a new scenario rather than editing the pinned one. Forking a pinned scenario breaks the pin: the fork is an ordinary, unpinned scenario that no longer follows the terms and can be edited freely.

9. Assumptions the mapping may return

Each assumption below is returned only when it actually applies to the modelled scenario, and is shown beside the result.

10. Versioning

This section is carried by Methodology M8, which documents rNPV model 4.0.0. The mapping itself is versioned separately and independently of the methodology text: term-model mapping v4. Mapping v4 refuses a set in which your organisation pays an upfront, milestone or royalty on the modelled asset (paid_terms_not_modelled) instead of listing that payment as not modelled (paying_side), because valuing only what your organisation receives would overstate its side; every set it still models gets the same scenario inputs as under v3. Mapping v3 does not model an upfront or milestone that is not allocated to one indication plan when the asset has more than one included plan, and names the per-indication assumption for revenue terms; it no longer returns ira_applied_to_whole_schedule, because model 4.0.0 applies the IRA cap to US revenue only. Mapping v2 wrote the same scenario inputs as v1 and dropped deal_revenue_at_lead_launch, because model 3.0.0 times deal revenue from each kept region's own launch. A scenario modelled under an earlier mapping keeps the model version and values it was computed with. The mapping adds no model input or output: no export, REST or MCP surface adds terms or the mapping to its payload; this section documents an application behaviour.