# DR-19, DR-42 and the line-quantity question — decision brief > ## CLOSED — 15 September 2026. All four recommendations accepted by Sky. > > Briefs 5 and 6 have been rewritten against them: > `M3-briefs/05-lines-rollout-and-period-overrides.md` and > `M3-briefs/06-the-multiplication-module.md`. > > **Register wording is at the end of this file.** *Update, 5 October 2026: the register entries > now exist in `crm/index.html` — DR-19 and DR-42 updated, and the three new decisions numbered > DR-62 (quantity), DR-63 (where a line hangs) and DR-64 (the business line).* **Written 15 September 2026**, from the ten-deal rollout validation. **Decision 4 added the same day**, after a third quotation showed variation between locations and not only between periods. Closing these unblocks Brief 5 and Brief 6; leaving them open means building the multiplication module to a model that two signed contracts already exceed. **The evidence is one line on one quotation**, `20260723-060802415` — [Advice] Chiang Rai (Revised), signed 28 Aug 2026: > **Giant Pumpkin - Digital Signage Subscription - PPU** — qty 1 — THB 11,760.00 > Start date: **the first of the following month after installation** > Billing frequency: **Annually (2 years upfront)** > Term length: **Free 3 months + 24 months** > Rate: Monthly **490 THB / Per Screen / Per Month** · Yearly **5,880 THB / Per Screen** · > 2 Year **11,760 THB / Per Screen** (24 months contract on software license) Everything below follows from that line and from `20260427-071511013` — [Advice] Hardware. --- # Decision 1 — DR-19 · billing frequency **Decision:** How does an opportunity line carry its recurring terms, given that a real line has a rate, a billing frequency, a term and a free period — and Brief 5 currently allows only *one-time* or *monthly*? **Recommended: store the monthly rate, the billing frequency, the term in months and the free months as four separate attributes on the line, and derive both revenue and cash from them.** The reason is arithmetic on the quote itself: **490 × 12 = 5,880 and 490 × 24 = 11,760.** The tiers carry **no discount**. They are prepayment options, not prices. So the monthly rate is the economic truth and frequency only moves cash — which means one rate plus a frequency reproduces all three quoted figures exactly, and the alternative does not reproduce the rate at all. ### Option A — monthly rate + frequency + term + free months *(recommended)* Line stores: `unit_rate_monthly`, `billing_frequency` (monthly · annual · biennial-upfront · one-time), `term_months`, `free_months`. - **Pros:** MRR, ARR and TCV all derive from one number; cash schedule derives separately; reproduces every figure on the quote; a future non-monthly cadence is a new enum value, not a new model. - **Cons:** four attributes where the brief had one; the quote's printed total becomes derived rather than stored, so a quote that disagrees with its own arithmetic is now visible — arguably a feature. - **Risk:** a deal that genuinely discounts the annual tier cannot be expressed. **Mitigate with an optional explicit period price that overrides the derivation when set**, and flag on the opportunity when it is used. ### Option B — store the quoted period price and a duration Line stores THB 11,760 and "24 months". - **Pros:** matches the document exactly; no derivation to get wrong. - **Cons:** MRR must be back-derived by division, which is lossy the moment a term is not a whole number of billing periods; a discount is indistinguishable from a different rate; **and every forecast in M6 needs MRR, so the division happens anyway — just in more places.** - **Risk:** the same subscription quoted monthly and biennially produces two different-looking lines for identical economics. ### Option C — extend the billing-basis enum only Add *annual* to one-time/monthly and stop there. - **Pros:** smallest change to Brief 5. - **Cons:** **cannot represent this contract at all** — no term, no free period, no prepayment. The Chiang Rai line would be stored as "annual, 11,760" which is wrong in three ways. - **Risk:** it looks like it works until the first forecast. **Impact:** commits M3's line to carrying recurring terms rather than deferring them to the subscription record in M6. It also means **M5's quote lines inherit the same four attributes**, and M6's subscription is created from them rather than re-entered. **Constraint:** DR-19 is recorded as blocking **M5**. The evidence moves it to **M3**, because the billing basis sits on the opportunity line and the multiplication module reads it. That is a change to the register's dependency, not to DR-19's substance. --- # Decision 2 — DR-42 · activation date **Decision:** What determines when a line's recurring revenue starts, given the quote says *"the first of the following month after installation"* — a rule relative to a deployment event, not a date anyone types? **Recommended: store an activation *mode* on the line; M3 forecasts from the rollout period's month by applying that mode; the actual installation date supersedes the forecast later and is not M3's to hold.** This keeps M3 honest about what it is: **a forecast.** The opportunity does not know when a site was installed — Airtable's `Jobs` does, and in ConnectIQ that will be Field Operations. What the opportunity knows is which month a location is scheduled to arrive, and what rule converts that into a billing start. ### Option A — activation mode on the line, forecast from the rollout period *(recommended)* `activation_mode` enum: *first of month after installation* · *on installation* · *fixed date* · *on signature*. Forecast start = the rollout period's month, plus the mode's offset, plus `free_months`. - **Pros:** reproduces the quoted behaviour; keeps the forecast independent of deployment data M3 cannot see; the mode is a small enum that M5's quote and M6's subscription both reuse. - **Cons:** the forecast is approximate at day granularity — it assumes a site installs within its rollout month. - **Risk:** if a site slips a month, the forecast is a month out until actuals arrive. **Acceptable — it is a forecast, and the slip is visible in Ops.** ### Option B — an entered activation date per line - **Pros:** exact. - **Cons:** **nobody has the date at quote time**, which is precisely when the forecast is needed; it would be entered as a guess and then never corrected. - **Risk:** a stored date that looks authoritative and is not. ### Option C — no activation concept in M3; revenue starts at the rollout period - **Pros:** what Brief 6 assumes today; simplest. - **Cons:** **wrong for every site on the Advice deal.** Chiang Rai installs 2027-01-06; revenue starts 2027-05-01 after the free period. Four months of error per site, compounding across a rollout. - **Risk:** the first forecast a rep checks against reality is wrong, on the milestone whose exit criterion is a rep trusting it. **Impact:** M3's month-by-month series becomes *installation month → activation offset → free period → billing*. That is three more steps than Brief 6 describes, and it is the difference between a forecast that matches the contract and one that does not. **Constraint:** DR-42 is recorded against **M5/M6** (activation dates and modes, and change orders). Only the **mode on the line** and the **forecast derivation** move to M3. Actual activation, change orders and the subscription lifecycle stay where they are. --- # Decision 3 — what a line's quantity means · **not yet a DR, and it should be** **Decision:** Does a line's quantity mean *units per location*, or *units across the whole deal*? Brief 5 says per-location. Live contracts do both, and nothing on the line distinguishes them. The proof is two quotations from the same opportunity: | Quote | Line | Qty | Meaning | |---|---|---|---| | `071511013` Hardware, signed 29 Apr | LG - 43UH5Q-EQ | **5** | **five units across five sites** | | `060802415` Chiang Rai, signed 28 Aug | LG - 43UH5Q-EQ | **1** | **one unit for one site** | Brief 5's rule — *licence count = software units per location × total locations* — applied to the first line gives **5 × 11 = 55 displays** for a deal that bought eleven. **Recommended: every line declares its quantity basis — *per location* or *deal total* — and the multiplication multiplies only the per-location ones.** ### Option A — a `quantity_basis` flag on every line *(recommended)* - **Pros:** one attribute; makes the ambiguity impossible rather than conventional; the multiplication module reads it and cannot get it wrong silently. - **Cons:** a rep must choose, and will sometimes choose wrong. - **Risk:** low. A wrong flag produces an obviously wrong total, not a subtly wrong one. ### Option B — per-location only; bulk purchases become a separate opportunity - **Pros:** keeps Brief 5's model exactly as written. - **Cons:** **contradicts how the business actually sells** — the Advice deal bought hardware in bulk under the same opportunity, deliberately, and splitting it would break the deal's own reporting. - **Risk:** reps work around it by entering bulk quantities as per-location, which is the failure this decision exists to prevent, arriving silently. ### Option C — infer from category Hardware is bulk, software is per-location. - **Pros:** no new attribute. - **Cons:** **false on the evidence** — the Chiang Rai quote's hardware is per-location. - **Risk:** a rule that is right often enough to be trusted and wrong often enough to matter. **Impact:** this is the single change that most affects the multiplication module. **It should be a numbered decision in the register**, because Brief 5 cannot be rewritten without it and no existing DR covers it. --- # Decision 4 — does a line describe *the* location, or *a* location? **Added 15 September 2026 after a third quotation.** This is the largest of the four and it was not visible until three quotes from one opportunity were read side by side. **Decision:** Brief 5 says lines describe **what a single location receives, expressed once per site before any document exists.** Two sites on the Advice opportunity receive **different products at different prices**. Does a line therefore hang off the opportunity, or off a location? The evidence, three signed quotations, one opportunity: | | Hardware (bulk ×5) | Chiang Rai | Chaiyaphum | |---|---|---|---| | Display | LG - **43UH5Q-EQ** | LG - **43UH5Q-EQ** | LG - **43UH7N-EP** | | Delivery / Transportation | *(excluded)* | THB **7,000** | THB **4,400** | | Subtotal | — | THB 75,100 | THB 72,500 | Every other line matches to the baht. **The SKU and the price both vary by site.** **Recommended: keep lines on the opportunity as the deal's *default* bundle, and allow a location to override individual lines. Do not make every line per-location.** Most sites on this deal *are* identical. Forcing eleven copies of a five-line bundle to express two differences would be worse than the problem, and it would make an opportunity's shape unreadable at the moment a rep is trying to price it. ### Option A — opportunity-level lines, with per-location overrides *(recommended)* The opportunity carries the standard bundle. A location may override a line's product, its price, or both. The multiplication uses the override where present and the default otherwise. - **Pros:** the common case stays one bundle; variation is expressible and **visible**; the multiplication stays a single pass; an opportunity with no overrides behaves exactly as Brief 5 describes today. - **Cons:** two places to look for a line's price; the forecast must resolve overrides before multiplying. - **Risk:** overrides are entered and then forgotten, so a deal's headline bundle stops matching what sites actually get. **Mitigate by surfacing an override count on the opportunity** — the same discipline DR-46 applies to unattributed brands. ### Option B — lines always hang off a location - **Pros:** one place to look; no resolution step; exactly matches how quotes are actually written. - **Cons:** a rep pricing an eleven-site deal enters fifty-five lines; **and the opportunity has no bundle at all**, so there is nothing to show before the site list exists — which is precisely when a forecast is most needed. - **Risk:** the deal cannot be forecast until every site is known. Most deals are forecast long before that. ### Option C — accept the loss; one bundle, no variation - **Pros:** Brief 5 unchanged. - **Cons:** **wrong on the second deal examined.** The forecast would price every Advice site at Chiang Rai's THB 75,100 and overstate the deal. - **Risk:** silent. Nobody checks a forecast against eleven individual quotes. **Impact:** this is the decision that determines whether `com_opportunity_lines` is one table or two, and it is the largest single change to Brief 5. ## A tension to state plainly, not to resolve quietly **DR-08 removed the Site Package**, and this decision puts something site-shaped back. They are not the same thing, and the distinction matters. **DR-08 removed a *reusable* package — an entity justified by reuse across opportunities, which was never once used that way.** What the evidence now asks for is **per-site variation within one opportunity**, which has nothing to do with reuse and is observed rather than hypothesised. **But it is close enough that it must be decided deliberately, not assumed.** If Option A is taken, say in the register that DR-08 stands and why this is a different thing. If that reasoning does not hold up, the honest conclusion is that DR-08 needs revisiting — which is a decision, not something for a builder to discover in a diff. --- # What changes in the briefs once these close | Brief | Change | |---|---| | **05** — lines and rollout | Rewritten. Line gains `quantity_basis`, `unit_rate_monthly`, `billing_frequency`, `term_months`, `free_months`, `activation_mode`, and a unit of measure (**screen**, not location — see below). Category/billing-basis table replaced. **Plus whatever Decision 4 settles about per-location overrides** — potentially a second table. | | **06** — multiplication | Series becomes rollout month → activation offset → free period → billing. A **second series for cash** where prepayment applies. Rewritten, not amended. | | **07** — board/list/forecast | Unchanged in shape; the forecast view now shows a materially different series. | | **01–04** | **Unaffected. These can start now.** | ## Two smaller things the same evidence settles - **The licence unit is the screen, not the location.** *"490 THB / Per Screen / Per Month"*. Brief 5's formula agrees only when a site has one screen, and nothing on a quote says it does. - **Delivery / transportation is a priced per-site service line** (THB 7,000, carrying a delivery address). Brief 5's *Services* category covers it; note it varies by site and was absent from the bulk wave. ## What this costs **DR-30's checkpoint is unchanged and now matters more:** M3 at ten days or fewer keeps end-October alive; fifteen or more means the date gets restated then rather than in December. The handover's instruction not to re-open the scope-versus-clock argument stands, and this is not that argument. **It is the ten-deal validation doing exactly what it was put in the plan to do** — finding out that the model was wrong while it was still cheap. The cost of closing these three decisions now is one planning session. The cost of not closing them is the one thing Brief 6 says is unrecoverable. --- # Register wording — for `crm/index.html` **The two new decisions need numbers.** Wording below is final; the IDs are not. ### DR-19 — billing frequency · **closed 15 September 2026** An opportunity line carries **`billing_basis`** (one-time or recurring), **`unit_price`** — which for a recurring line is the price *per unit per month* — **`billing_frequency`** (monthly, annual, biennial upfront), **`term_months`** and **`free_months`**. Revenue derives from the rate; cash timing derives from the frequency; they are independent. Evidence: quote `20260723-060802415` offers 490/screen/month, 5,880/year and 11,760/2-year, and **490 × 24 = 11,760** — the tiers carry no discount, so they are prepayment options rather than prices. An optional `prepaid_period_price` overrides the derivation where a prepayment is genuinely discounted, so that its use is visible. **DR-19 was recorded as blocking M5. It binds M3**, because the billing basis sits on the opportunity line and the multiplication module reads it. ### DR-42 (line-level part only) — activation · **closed 15 September 2026** An opportunity line carries an **`activation_mode`** — `first_of_month_after_install`, `on_install`, `on_signature` or `fixed_date` — **not an activation date.** M3 forecasts the start from the rollout period's month plus the mode's offset plus `free_months`. Actual installation dates live in Field Operations and supersede the forecast; **DR-42 keeps actual activation, change orders and the subscription lifecycle for M5/M6.** Evidence: quote `20260723-060802415` prints *"Start date: the first of the following month after installation."* Nobody has that date at quote time, which is when the forecast is needed. ### DR-62 — what a line's quantity means · **closed 15 September 2026** Every opportunity line declares a **`quantity_basis`**: **`per_location`** (multiplied by the location count) or **`deal_total`** (never multiplied). Evidence: on one opportunity, quote `20260427-071511013` lists `LG - 43UH5Q-EQ × 5` meaning five units across five sites, while `20260723-060802415` lists the same product `× 1` meaning one unit for one site. Without the flag, the superseded rule *licence count = units per location × total locations* computes **55 displays for a deal that bought eleven.** ### DR-63 — where a line hangs · **closed 15 September 2026** Opportunity lines describe the deal's **default bundle**. A **rollout period** may override individual lines — product, price, quantity, or any combination — through `com_opportunity_period_line_overrides`. **Overrides key to the period, not to a named location**, because an opportunity carries location *counts* rather than named sites, and at forecast time the sites frequently do not exist as records. Evidence: on one opportunity, Chaiyaphum (installed 2026-05) received `LG - 43UH7N-EP` with delivery at THB 4,400, while Chiang Rai (installed 2027-01) received `LG - 43UH5Q-EQ` with delivery at THB 7,000. Every other line matched to the baht. **Both differences fall between periods**, which is why period-keyed overrides are sufficient for the evidence in hand. **Known limit, recorded deliberately:** two sites going live in the *same* period cannot differ. No deal examined requires it. The remaining eight deals in the ten-deal validation should be checked against this specifically; if one needs it, the table gains a location dimension and that is a new decision. **DR-08 stands.** It removed a *reusable* Site Package — an entity justified by reuse across opportunities that was never once used that way. This is per-period variation *within* one opportunity, observed in signed contracts, with no reuse and no identity outside its opportunity. The two are different, and the difference is recorded here rather than assumed. ### DR-64 — the business line on the opportunity · **closed 5 October 2026** **Closed by Sky, 5 October 2026, as built:** the column is `com_opportunities.business_line` (the name `business_line` is accepted, not `service`); it is `not null` with no default, because every deal examined is exactly one line, so DR-46's reversal does not apply; the values are `digital_signage` and `music_streaming`; and **a deal that sells both lines is entered as two opportunities, one per line** — there is no third value. The three questions below were open when the text was written; this decision answers them. *The wording below is as written on 16 September 2026.* Giant Pumpkin runs two business lines — **digital signage** (TVs and monitors with display-management software) and **music streaming** (the Lisa box). They differ in economics, not just in product: signage hardware is priced and installed, music hardware is bundled at THB 0 and delivered. Every HubSpot deal carries `Service` and every Airtable quote carries `Quote Service (HS)` as a controlled two-value vocabulary. **`com_opportunities` has no equivalent column.** `labels` is not a substitute — it is free text and drifts. Deriving the line from the opportunity's categories fails for a deal with no lines yet, which is every opportunity at the moment it is being forecast, and for repairs, whose categories say nothing about the line. **This is DR-46's argument again:** revenue split by business line is a certainty for M6, and a column added after deals exist means attributing history by memory. Build brief: `M3-briefs/01R-opportunity-columns.md`. **Three things it leaves open deliberately** — the column's name, whether it is required (DR-46 chose *required* and reversed it; the parallel is not exact, because a deal is always one line or the other), and what a deal spanning both lines does. ### Also settled by the same evidence, not needing their own entries - **The licence unit is the screen, not the location** — *"490 THB / Per Screen / Per Month."* - **Forecasts are ex-VAT.** Quotes carry 7% VAT; the model has no tax field, and that is a decision. - **Category classifies; `billing_basis` bills.** Category no longer determines billing basis, and the category vocabulary is extensible — live quotes show Display, Player Box, Software, Installation and Delivery.