File: 2026.10.26 - Lumenwire Audio - 01 Business Requirements.md

Lumenwire Audio: Business Requirements

Test case. Lumenwire Audio is a made-up company. Marcus was played by the case's stakeholder agent. Data is Sample data.

1. Document control

2. Problem Statement

Revenue fell by about a third in a year, from A$118.4m to A$80.6m, and the board was caught by surprise because nobody puts the Finance, Sales and Engineering numbers together. Nobody can yet show, from one set of numbers everyone trusts, whether the business is still growing underneath the fall.

As stated by Marcus: Revenue went from A$118.4m in FY25 to A$80.6m in FY26, down about a third. The board says they were blindsided, and Ros (chair) wants to see the business properly, not just a quarterly P&L. The board wants revenue back to A$115m within two years and a view it can trust each month. Marcus believes hardware fell because of an industry soft patch (tariffs, interest rates, delayed venue projects, cautious OEMs), while software grew 38% to A$25.7m, gross margin rose from 71% to 77%, and there was a record 1,180 design wins. Q1 FY27 came in at about A$19m.

As Gary understands it: The fall itself is known. What's missing is one joined-up view that tells the board whether the business underneath is healthy or whether more falls are coming. Marcus has a story he wants the board to see, but by his own account: design-win conversion has never been measured, the CRM is bonus-driven, the forecasts aren't trusted, and the telemetry has never been used as an end-customer view. The dashboard has to test that story, not just tell it. The word to come back to is Marcus's own: "growing underneath the fall".

3. Objectives

4. Audience and decisions

5. Business Requirements with Data Mapping

Owners are roles. Targets and thresholds are Gary's proposals unless marked "Marcus". Every measure is marked Draft: Kewpie to confirm.

5.1 Top 5 KPIs (what and why)

5.2 Targets, thresholds and sign-off

5.3 How measured (Draft: Kewpie to confirm)

5.4 Sub-KPIs (they explain a Top 5 KPI)

6. Backlog (Nice to Haves)

7. Data inventory

History and refresh for every system are unknown to Marcus (Q-6). Sample data ranges shown for reference only.

8. Constraints and chart preferences

• One page, monthly, for the chair and the board; on screen as well as in the board pack
• Things people in the business can act on. No "accountant metrics" (Marcus)
• Sales and Finance use the same numbers
• New devices activated (K2) and Forecast accuracy (K5) stay off page one until the Head of Platform Engineering and the CFO have given their view
• Naming OEMs on the board page: CFO and legal to decide. Be careful naming customers
• Show the trend towards A$115m, not a single point. All three outcomes on one page
• Tools and other chart preferences: ask the VP Sales or CFO

9. Assumptions

10. Open questions

Due dates are Gary's proposal.

11. Change log

File: 2026.10.26 - Lumenwire Audio - 02 KPI Calculation Pack.md

Lumenwire Audio: KPI Calculation Pack

Stage 2 (KPI Development), Kewpie. Version 1.0, 26-Oct-26. Built on Business Requirements v1.0 (approved 26-Oct-26, no changes).

Data label: Sample data. Synthetic data for the test run. Latest complete month: September 2026 (the data ends 30 September 2026). Financial year runs July to June.

Re-run: 03 - Working Files/02_calculations.py reads the 18 CSVs and writes 02_results.json. 02_build_pack.py turns that into this pack, the challenge notes and the Kewpie columns of spec.json. Every number and every root cause test below comes from those two scripts, so any figure can be re-run and checked.

Two things Gary flagged, and where they landed

• Reps are paid per design win with no clawback: the design-win counts sit under the conversion rate, and the Root Cause Findings test whether the bonus changed anything (it changed volume and deal size, not the shipping rate so far).
• Forecast data mixes units: 12 of 84 snapshot rows are in AUD thousands (FY24-Q1, FY24-Q2, FY24-Q3, FY24-Q4, Finance only). All are converted to AUD before any calculation. Left unconverted, Finance's first forecast would be out by 99.9%.

Pending sign-off, built anyway. New devices activated (K2) is pending the Head of Platform Engineering. Forecast accuracy (K5) is pending the CFO. Both are built and tested below and carry that flag. Neither goes on page one until the person named has given their view.

1. Summary: the Top 5

All five baselines are Observed Fact on the Sample data, except Design wins that ship (K4), which is a Working Hypothesis: 33% of the design wins the CRM knows about have no stage dates and cannot be counted (above the 5% rule).

Reading the pace column. Total revenue (K1) is flat at about A$80.5m, so it needs A$1.64m a month more to reach A$115m. Software growth (K3) looks near target only because of one licence. Without it, the pace needed is about twice the run rate.

What the data says about the story Marcus told

2. The Top 5 and their sub-KPIs

Each measure below is Confirmed (Gary's draft ran as written) or Corrected (changed, with the Before and After in section 5, and logged as a challenge note where it affects the target or the data).

Total revenue, last 12 months, against the path to A$115m (K1)

Measure status: Corrected (hardware and other revenue split). Objective: Get revenue back to A$115m within two years (O1). Owner: CEO.

• Plain English: Revenue over the last 12 months, shown each month against a straight line from FY26 actual (A$80.6m) to A$115m by June 2028. Split hardware and software.
• Calculation: R12M(m) = -1 x SUM(gl_monthly.amount_aud) over the 12 months to month m, for account codes 4000, 4050, 4100, 4110, 4200, 4210. path(m) = 80.6m + (115m - 80.6m) x months since Jun-26 / 24. gap = R12M - path.
• Sources and why: gl_monthly.amount_aud, period, account_code and gl_accounts.pl_group: the ledger Marcus trusts and the board pack uses. Cross-check: erp_invoice_lines.net_amount_aud by product_family reconciles to the ledger by financial year and family, largest difference A$0.00.
• Grain: month by account (summed over cost centres).
• Filters: pl_group 'revenue' (6 accounts); credits flipped to positive; volume rebates (4050, debit) reduce revenue and freight recovered (4210) is included. This reproduces A$118.4m (FY25) and A$80.6m (FY26) exactly. Hardware = 4000 + 4050. Software = 4100 + 4110. Other = 4200 + 4210 (developer kits and freight).
• Baseline: A$80.54m for the 12 months to Sep-26 (hardware A$54.8m, software A$25.1m). Path at Sep-26: A$84.9m. Gap -A$4.36m (-5.14%), just beyond the 5% Red line. Observed Fact. Peak was A$122.1m in 2024-06.
• Pace needed: (A$115m - A$80.54m) / 21 months to Jun-28 = A$1.64m a month. The straight-line path itself rises A$1.43m a month. Run rate over the last 3 months: -A$0.02m a month. Off pace.
• Counter-metric: Gross margin %, last 12 months (K3.2), baseline 76.5%. Revenue can be pulled forward with volume rebates: in FY25, 46% of hardware revenue landed in the four quarter-end months (rebates are only ever booked in those months), against 33% if spread evenly. Watch the margin and the rebate rate (6.7% of hardware sales in FY25, 4.6% in FY26).
• Notes: The R12M contains the A$7.4m licence of Mar-26 (9% of the figure). If the rest of FY27 repeats last year month by month without that licence, the 12 months to Jun-27 would be about A$73.1m, against a path of A$97.8m (an illustration, not a forecast). Hardware has been flat for five quarters (FY26-Q1 to FY27-Q1: A$12.9m, A$14.5m, A$12.6m, A$14.4m, A$13.4m). FY27-Q1 is +3.9% on the year before, the first quarter that is not a fall. No unmapped accounts, no duplicate ledger rows.

Sub-KPIs under Total revenue: none

Gary's list has no sub-KPI under K1. The split by hardware and software is shown inside K1, and the reasons for the movement are in the Root Cause Findings.

New devices activated in the field, last 12 months against the year before (K2)

Measure status: Corrected (repeat serials and OEM backfill). Objective: Know whether we're still growing underneath the fall (O1.1). Owner: VP Sales. Pending sign-off: Head of Platform Engineering (Tomasz Wierzbicki).

• Plain English: Devices that joined a network for the first time in the last 12 months, against the 12 months before.
• Calculation: keep the earliest first_seen_ts per device_serial; activations(R12M) = 10 x COUNT(device_serial) where that first date is in the 12 months to Sep-26; growth = this / prior 12 months - 1. The table is a 1-in-10 sample, so counts are multiplied by 10 (growth % is unaffected).
• Sources and why: device_activations.device_serial, first_seen_ts (engineering telemetry, the source Marcus trusts most); oem_id, country_from_ip, module_sku for the splits.
• Grain: device (first activation).
• Filters: one row per serial (5,040 repeat rows dropped, 0.42% of rows); beta-firmware rows are all from 2021-22 and none fall in the window (0); data starts Jan-21; 107,210 rows have no oem_id (8.9%): 22,024 are recovered through manufacturer_code (each code maps to one OEM) and 85,186 stay unassigned. This affects only the OEM split, not the headline.
• Baseline: -1.4% for the 12 months to Sep-26 (2,492,460 against 2,528,350). The year before was +3.0%. Observed Fact on the sample. Last quarter alone (Jul to Sep 26 against the same months of 2025): +4.9%.
• Pace needed: (+5.0% - (-1.4%)) / 9 months to Jun-27 = +0.71 pts a month. Run rate: +0.63 pts a month. Slightly off pace, and closing.
• Counter-metric: Share of activations that are repeat serials (a device re-joining counted as new), baseline 0.51% in the 12 months to Sep-26. It guards against re-flashed or test devices inflating the count.
• Notes: Coverage is the open question (Q-4): the sample cannot say what share of installed devices phone home. Telemetry is a clue for end-customer demand, not yet proof. In the data, units invoiced per device activated were 1.91 in Jan to Jun 25 and 1.04 since Jul-25 (see the Root Cause Findings for what that implies). Duplicate-serial share is steady (0.47% before the dip, 0.53% during).

Sub-KPI under New devices activated: OEM stock on hand, top 40 OEMs (K2.1)

Measure status: Corrected (reels, free-text names, 35 reporters not 40). Owner: VP Sales. Pending the Head of Platform Engineering and VP Sales.

• Plain English: Units of our parts the reporting OEMs hold, by calendar quarter, compared only across the OEMs that reported in both quarters.
• Calculation: SUM(units) by quarter, where units = units_on_hand x 500 for rows described as reels of 500, otherwise units_on_hand. Quarter-on-quarter change uses only OEMs that reported in both quarters.
• Sources and why: oem_inventory_reports.oem_name, quarter, sku_or_description, units_on_hand (Sales; the only stock view we have); oem_master.oem_name to match names.
• Grain: OEM by quarter by SKU line.
• Filters: 235 spellings of OEM names clean up to 35 OEMs (case, spacing, hyphens and company suffixes), and all match oem_master. 88 rows are reels of 500 (counts of 3 to 117, converted to units). 229 rows are finished goods containing our parts: kept, but they are not loose stock. No duplicate rows. Calendar quarters.
• Baseline: 841,883 units reported by 28 OEMs in 2026-Q3. Peak 1,590,583 in 2025-Q2 (31 OEMs). Like for like (OEMs reporting in both quarters), stock fell 17.1% in 2026-Q3 on 2026-Q2, and 45.4% from the 2025-Q2 peak to 2026-Q3 (25 OEMs reporting in both). Observed Fact for the reporters; coverage is 46% of FY26 hardware revenue.
• Pace needed: none yet: Gary's target and thresholds are 'to be agreed after the baseline'. Run rate (average like-for-like quarterly change, last 3 quarters): -12.3% a quarter.
• Counter-metric: not required for a sub-KPI. Reporting is voluntary and uneven (22 to 31 OEMs a quarter), so always show how many OEMs reported.
• Notes: Only 35 OEMs report, not 40. Stock at the reporters is still 9.3 months of their current purchases (it was 7.9 at the peak, because purchases fell faster than stock). A reading of 'destocking is over' is not supported yet. Notes on the reports vary (includes goods in transit: 163, excludes Mexico plant: 162, estimate: 157, as at month end: 123), so definitions differ by OEM.

Software revenue growth, last 12 months against the year before (K3)

Measure status: Confirmed. Objective: Keep software growing, with gross margin holding up (O2). Owner: CEO.

• Plain English: Software revenue over the last 12 months divided by the 12 months before, minus 1.
• Calculation: -1 x SUM(gl_monthly.amount_aud) for account codes 4100 and 4110 over the 12 months to Sep-26, divided by the same for the 12 months before, minus 1.
• Sources and why: gl_monthly (the P&L). Cross-check: software_licences.contract_value_aud by start_date equals the ledger within A$27k in any month and A$13k over FY26. The ledger books software at the licence start date, for annual subscriptions as well as perpetual licences.
• Grain: month by account.
• Filters: accounts 4100 and 4110 only; sign flipped; latest complete month Sep-26.
• Baseline: +19.7% for the 12 months to Sep-26 (A$25.1m against A$21.0m). FY26 was +38.2%, reproducing Marcus's 38%. Observed Fact. Without the A$7.4m licence of 2026-03-27: -15.6% (-1.6% for FY26).
• Pace needed: to reach +20% for FY27, software must be A$30.8m. With A$5.85m booked in Jul to Sep 26, the other 9 months need A$2.78m a month. Trailing software without the licence runs at A$1.48m a month. Run rate of the growth figure: -6.2 pts a month, because the 12-month base now contains a very large month (the 2026-03 licence stays in the figure until Mar-27, then drops out and growth falls to about -31% by Jun-27 if the rest of the year repeats last year without a new deal like it).
• Counter-metric: Renewal rate of annual subscriptions due in the last 12 months (renewed / (renewed + lapsed)), baseline 88.7% (328 contracts decided; 75 still pending and 88 with no status are left out). Prior 12 months: 88.2%. It guards against growth built on contracts that do not renew.
• Notes: The licence table has 1,750 of 3,096 contracts with no oem_id. The A$7.4m contract has 0 seats (the only contract in the table with none), is a perpetual licence, and belongs to Corvane (OEM0079), which was our largest hardware customer in FY25 (A$5.4m) and bought 53% less in FY26. What the contract is, is a question for the CFO. This pack is internal; do not name the customer on the board page until the CFO and legal decide (Q-7).

Sub-KPI under Software revenue growth: Share of software revenue from the largest licences (K3.1)

Measure status: Confirmed. Owner: VP Sales.

• Plain English: The largest licence (and the largest five) as a % of all software contract value started in the last 12 months.
• Calculation: MAX(contract_value_aud) / SUM(contract_value_aud) for software_licences with start_date in the 12 months to Sep-26. Top 5 likewise.
• Sources and why: software_licences.contract_value_aud, start_date, customer_name, licence_type (the contract detail Finance holds).
• Grain: licence contract. Filters: start date in the last 12 months (617 contracts). Customer names stay off the board page (Q-7).
• Baseline: largest licence 29.4% of A$25.2m started; top 5 40.5%. Without the Mar-26 licence: largest 4.9%, top 5 18.4%. The year before: 3.9% and 14.6%. In no earlier financial year did the largest licence exceed 6.6%. Observed Fact. Status: Red (10% green line, 20% red line).
• Pace needed: target is below 10% by Jun-27: -19.4 pts. This happens on its own in Mar-27 when the licence leaves the 12-month window, so the figure will not show whether sales behaviour changed. Run rate: not meaningful (one contract).
• Counter-metric: not required for a sub-KPI.
• Notes: Even the second-largest licence is A$864k, so the cliff is one contract.

Sub-KPI under Software revenue growth: Gross margin %, last 12 months (K3.2)

Measure status: Confirmed. Owner: CFO.

• Plain English: (Revenue minus cost of sales) divided by revenue, over the last 12 months.
• Calculation: (R12M revenue - R12M cost_of_sales) / R12M revenue from gl_monthly by gl_accounts.pl_group (revenue accounts 4000 to 4210; cost of sales 5000 to 5100).
• Sources and why: gl_monthly, gl_accounts (the P&L). Grain: month by account. Filters: revenue sign flipped; all five cost-of-sales accounts included.
• Baseline: 76.5% for the 12 months to Sep-26 (72.3% the 12 months before). FY25 and FY26 reproduce Marcus's 71% and 77%. Observed Fact. Without the Mar-26 licence: 74.1% (assuming the licence carries no cost of sales; at the normal software rate of 4.5% the answer moves by under 0.5 pts). Status: Amber (77% green, 75% amber line).
• Pace needed: holding 77% by Jun-27 needs +0.06 pts a month. Run rate: -0.17 pts a month. When the licence leaves the window in Mar-27, margin falls to about 74.1% unless a similar deal lands.
• Counter-metric: not required for a sub-KPI.
• Notes: Hardware margin is 67.9% (from 66.8%); software 95.5%. Software is 31% of revenue (from 19%). Margin rises because the mix moved to software, not because hardware got cheaper to make.

Design wins that ship, as a % of design wins old enough to have shipped (K4)

Measure status: Corrected (dates required, shipped defined by the date, window kept at 18 months for the CFO and VP Sales to confirm). Objective: Keep design wins turning into shipping products (O3). Owner: VP Sales.

• Plain English: Of the opportunities that reached design win at least 18 months ago, the share that have since reached shipping.
• Calculation: COUNT(opp WHERE stage_entered_shipping is not blank) / COUNT(opp WHERE stage_entered_design_win <= as-of date - 18 months), among opportunities with a design-win date. Lost after design win counts as not shipped.
• Sources and why: crm_opportunities.stage_entered_design_win, stage_entered_shipping, stage_entered_lost (the CRM is where design wins are logged). Splits: owner, region, oem_id.
• Grain: opportunity (one OEM product).
• Filters: design-win date on or before 2025-03-30 (18 months before the data ends). Cohort runs 2023-01-01 to 2025-03-30. 2,932 of 8,990 CRM rows have no stage dates at all (all last edited before 2023): 1,914 of them sit at design win, pre-production or shipping, so they cannot be placed in the cohort. 349 opportunities have a shipping date but no design-win date: counted separately, not in the rate. The 'confirm shipping against invoices' cross-check in the draft cannot be done: the CRM has a product name and the ERP has a SKU, with no key between them.
• Baseline: 31.5% (672 shipped of 2,131). 7.1% were lost and 61.4% (1,308) are neither shipped nor lost. Working Hypothesis, because 33% of design-win-or-later records have no dates. Sensitivity: counting the undated records by their current stage gives 29.7%, so the result holds. Status: Red.
• Pace needed: (80% - 31.5%) / 9 months to Jun-27 = +5.4 pts a month. Run rate (the same measure as at Dec-25, Mar-26, Jun-26, Sep-26: 30.8%, 31.4%, 31.7%, 31.5%): +0.08 pts a month.
• Counter-metric: Share of design wins later lost, baseline 7.1% of the 18-month cohort. This is the clawback test in numbers: reps are paid A$400 per design win with no clawback, so a rising lost share would show wins logged to earn the bonus.
• Notes: Stage dates start in Jan-23, so there is no history before that. Shipped share by age for the Jan to Jun 2023 design wins (430 opportunities): 12 months 7%, 18 months 21%, 24 months 27%, 36 months 32%, 42 months 32%. The curve levels off near a third, so a longer window would not reach 80%. Q-11 (how long a design win should take to ship) is still open.

Sub-KPI under Design wins that ship: Months from design win to first shipment (K4.1)

Measure status: Corrected (only cohorts old enough). Owner: Head of Platform Engineering.

• Plain English: The median number of months from design win to first shipment, for design wins that shipped, grouped by the quarter of the design win.
• Calculation: MEDIAN(stage_entered_shipping - stage_entered_design_win) in months (days / 30.44), for cohorts at least 18 months old. Younger cohorts are left out because only the fastest have shipped, which makes their median look short.
• Sources and why: crm_opportunities stage dates. Grain: opportunity. Filters: both dates present; grouped by financial quarter of the design win.
• Baseline: median 15.0 months (middle half 11.9 to 18.9 months, 672 shipped). Including the young cohorts it would read 14.3. Observed Fact on dated records.
• Pace needed: none: target 'to be agreed after the baseline'. Run rate: -0.6 months per cohort over the last 3 cohorts (shorter, but those cohorts are the least mature, so this is not yet a real improvement).
• Counter-metric: not required for a sub-KPI. Notes: by design-win quarter, the median ranges between 13.3 and 16.2 months.

Sub-KPI under Design wins that ship: Design wins per quarter (K4.2)

Measure status: Confirmed. Owner: VP Sales.

• Plain English: Count of opportunities entering design win in the quarter. Calculation: COUNT(crm_opportunities WHERE stage_entered_design_win in the financial quarter).
• Sources and why: crm_opportunities.stage_entered_design_win. Grain: opportunity, counted once. Filters: financial quarters (July to June).
• Baseline: FY27-Q1 260 design wins; FY26 1,180 (reproduces Marcus's 1,180), FY25 1,020, FY24 950. Observed Fact.
• Pace needed: none: no standalone target (read with Design wins that ship). Run rate: +4.3 design wins a quarter over the last 3 full quarters. Rising count with a flat shipping rate is the pattern to watch.
• Counter-metric: not required for a sub-KPI. Notes: reps earn A$400 per design win, with no clawback (FY25 onward). At 1,180 design wins, that is about A$472k for FY26, assuming every dated win was paid (Strong Inference).

Forecast accuracy: actual quarterly revenue against the forecast at the start of the quarter (K5)

Measure status: Corrected (units, snapshot rule, family mapping, signed error). Objective: Get revenue back to A$115m within two years (O1). Owner: CFO. Pending sign-off: CFO (Priya Anand).

• Plain English: For each quarter, the gap between actual revenue and the forecast made at the start of that quarter, as a % of actual. Shown for Finance and for Sales, with the direction of the miss (positive = forecast too high).
• Calculation: error = (forecast - actual) / actual; accuracy = ABS(error). forecast = sum of the three product families (hardware, software, other) from the latest snapshot on or before the first day of the quarter, converted to AUD. actual = ledger revenue for the same families and quarter.
• Sources and why: forecast_snapshots.forecast_amount, amount_unit, source, forecast_quarter, snapshot_date, product_family (the forecasts as submitted); gl_monthly.amount_aud (actual).
• Grain: quarter by source by product family.
• Filters: 12 rows in AUD thousands multiplied by 1,000 (Finance, FY24 quarters). Snapshots sit 2 to 5 days before each quarter starts, so the rule 'on or before the first day' picks one clean snapshot per quarter. One Sales revision dated after the quarter began (13-Oct-25, FY26-Q2) is ignored; its effect is not tested here. The Sales snapshot for FY25-Q3 is missing (sales_crm FY25-Q3): that quarter is excluded for Sales and counted. Family mapping follows the board plan: hardware = 4000 + 4050, software = 4100 + 4110, other = 4200 + 4210 (the plan reproduces FY26 x 1.15 line by line on this mapping). 13 complete quarters: FY24-Q1 to FY27-Q1.
• Baseline: FY27-Q1 (Jul to Sep 26): Finance forecast A$16.1m, Sales A$24.4m, actual A$19.4m. Errors: Finance -17.2%, Sales +25.6%. Average absolute miss over the last 4 quarters: Finance 23.2%, Sales 34.3%. Over all quarters: Finance 18.7% (2 of 13 quarters within 5%), Sales 22.8% (0 of 12). Observed Fact. Status: Red.
• Pace needed: within 5% by FY27-Q4 (3 more quarters): Finance -4.1 pts a quarter from 17.2%. Run rate (change in the miss over the last 3 quarters): Finance -11.3 pts a quarter, Sales -4.5 pts a quarter. The quarterly miss is noisy (Finance: FY26-Q2 51.0%, FY26-Q3 8.1%, FY26-Q4 16.7%, FY27-Q1 17.2%), so one good quarter would not show control.
• Counter-metric: Signed bias (average forecast minus actual, as a % of actual) over the last 4 quarters: Finance +14.6%, Sales +34.3%. It stops a forecast looking accurate by being low-balled or padded in alternate quarters.
• Notes: Which forecast the CFO wants measured is still open (Q-5). Quarters where both forecasts exist: Finance 18.6% average miss, Sales 22.8%, and their simple average 17.8%. A rule that says 'next quarter equals last quarter' would have averaged 12.0% against Finance's 18.7%.

3. KPI tree

Problem: nobody can show, from one set of numbers, whether the business is still growing underneath the fall

O1  Get revenue back to A$115m within two years
    K1  Total revenue, last 12 months, against the path to A$115m ........ Red
    K5  Forecast accuracy (pending CFO) ................................ Red
  O1.1  Know whether we're still growing underneath the fall
    K2  New devices activated in the field (pending Head of Platform Eng.) Red
        K2.1  OEM stock on hand, top 40 OEMs ........................... no target yet
O2  Keep software growing, with gross margin holding up
    K3  Software revenue growth ........................................ Amber
        K3.1  Share of software revenue from the largest licences ...... Red
        K3.2  Gross margin %, last 12 months ........................... Amber
O3  Keep design wins turning into shipping products
    K4  Design wins that ship .......................................... Red
        K4.1  Months from design win to first shipment ................. no target yet
        K4.2  Design wins per quarter .................................. read with K4

Every sub-KPI rolls up to one of the Top 5, and every Top 5 KPI links to an objective. Backlog (not built, Gary's list): Underlying earnings (EBITDA); Design wins per quarter as a page-one headline; Paid software features switched on in the field.

4. Root Cause Findings

All five Top 5 KPIs are off target or have moved, so each one has a case file. Method: clues, suspects, tests, ruled out, verdict, solution options. Every test is in 02_calculations.py with its result in 02_results.json. Evidence labels: Observed Fact, Strong Inference, Working Hypothesis. Solution options are suggestions for Gary, the action owner and the subject matter expert. They are not actions or targets.

Case 1: Total revenue, last 12 months, against the path to A$115m (K1)

Clues. The 12-month figure fell from A$122.1m (2024-06) to A$80.5m. It did not slide: hardware revenue halved in one step, from A$25.7m in FY25-Q4 (Apr to Jun 25) to A$12.9m in FY26-Q1 (-50%), then stayed flat for five quarters at A$12.6m to A$14.5m. Software added one A$7.4m licence in Mar-26. The fall is in units: OEMs bought 47% fewer in FY26 (4,883,606 to 2,590,114), at an average price 0.9% higher.

Bridge, FY25 to FY26 (the A$37.8m fall)

Suspects and tests

Timing check. Quoted lead times fell from about 48 weeks to about 8 between Sep-23 and Jun-24. Orders then collapsed (27,327 units a month in Oct-23 to Jun-24 against 400,190 before) while invoices carried on from the order book. Orders came back at about twice installs (412,052 a month against 210,839) from Jul-24 to Apr-25, and revenue held until Jun-25. From May-25 orders matched installs (214,392 against 207,237), and the revenue step arrived in Jul-25. The cause (OEMs buying more than their installs) came before the effect (revenue stepping down when they stopped).

Verdict.

1. Hardware sell-in fell to match installs: about A$48.0m of a A$49.8m hardware volume fall. The bridge adds up to the A$37.8m fall with A$0.0m unexplained. Bridge arithmetic: Observed Fact. The reading that OEMs bought ahead of need for two years and have now stopped: Strong Inference (timing fits and the other suspects are ruled out, but we cannot see the OEMs' own reasons).
2. End-customer demand: A$1.8m. Real but small. Observed Fact on the sample, with coverage of the telemetry unconfirmed (Q-4).
3. Two offsets hid part of the fall: the Mar-26 licence (A$7.4m) and smaller rebates (A$4.5m).
4. How big the stock overhang was is a Working Hypothesis. Units invoiced exceeded units activated by about 6.9 million from Jul-22 to Jun-25. The 35 reporting OEMs held at most 1.6 million at the peak and cover 46% of hardware revenue. Either the other OEMs hold a lot, or the telemetry sees only part of the installed base. The data cannot separate the two.

What it means for the path. Since Jul-25 invoiced units sit close to installs (1.04x), so hardware is no longer being pulled down by a sell-in gap. If installs stay flat, hardware revenue stays near A$13.4m a quarter. Getting back to A$115m then needs growth that no current measure shows. Stock reports still show 9.3 months of cover at the reporting OEMs, so further destocking is possible.

Data that would settle the open parts. The Head of Platform Engineering on telemetry coverage and the share of devices that phone home (Q-4). Stock reports from all Tier A and B OEMs, not 35 voluntary ones (VP Sales). The rebate scheme terms by quarter (CFO). Why OEMs ordered at twice installs from Jul-24 to Apr-25: a direct question to the top 10 OEMs.

Solution options (for the CEO, CFO and VP Sales to weigh).

1. Build the hardware forecast and plan from installs and OEM stock rather than last year's invoices (moves Total revenue K1 and Forecast accuracy K5).
2. Ask the top 10 OEMs for monthly stock and their own sell-through, to see whether the overhang is gone (moves OEM stock on hand K2.1 and Total revenue K1).
3. Review how volume rebates are tiered, because buying piled into quarter-end months (moves Total revenue K1 and its margin counter-metric).

Case 2: New devices activated in the field (K2)

Clues. The 12-month growth is -1.4%, below the +5% target. The monthly detail is sharper: every month from Jul-24 to Jun-25 was up on the year before (average +5.0%); every month from Jul-25 to Jun-26 was down (average -3.3%); Jul to Sep 26 is up again at +4.9%. Quarter by quarter: FY25-Q4 +4.9%, FY26-Q1 -3.2%, FY26-Q2 -3.3%, FY26-Q3 -4.1%, FY26-Q4 -2.7%, FY27-Q1 +4.9%. The 12-month figure still contains nine down months and three up months.

Verdict. The shortfall is a 12-month dip of about 3.3% that was broad across countries and products, followed by a recovery to +4.9% in the latest quarter. Effect on the 12-month figure: 35,890 fewer devices than the year before (1.4%). The dip and the hardware sell-in reset both start in July 2025. That is a clue, not a confession: the sell-in reset is fully explained without it (installs explain 4% of the unit fall). The cause of the dip is not settled by this data. Dip and recovery facts: Observed Fact. Any cause: Working Hypothesis.

Data that would settle it. The Head of Platform Engineering on whether firmware 4.5.0 changed when a device reports its first activation, and on coverage (Q-4). Sell-through from the top 10 OEMs for H2 2025.

Solution options.

1. Ask the Head of Platform Engineering to confirm the firmware and coverage question before the board sees this measure (moves New devices activated K2).
2. Show the latest quarter's growth beside the 12-month figure, because the 12-month figure lags a turn by about nine months (a display choice for Viktor and Gary).
3. Ask the VP Sales to check with the top 10 OEMs why their end sales dipped in H2 2025 and recovered (moves K2 and the sell-in view).

Case 3: Software revenue growth (K3)

Clues. Growth over the 12 months to Sep-26 is +19.7% (FY26: +38.2%). March 2026 software revenue was A$8.3m; a normal month is A$0.6m to A$2.3m. The licence table shows why: one perpetual licence, A$7.4m, Corvane (OEM0079), signed 2026-03-27, with 0 seats.

Bridge, 12 months to Sep-25 to 12 months to Sep-26

Verdict. Software growth is one contract. It adds A$7.4m, worth 35 points of growth (the figure is 19.7% with it). Without it software is -15.6% over 12 months and -1.6% for FY26. Numbers: Observed Fact. That it will not repeat: Strong Inference (a single contract at 29% of the year's new contract value, 9 times the next largest, in a year when no other licence topped A$864k). What the contract actually is: unknown. The FY27 board plan repeats it (plan software for Mar-27 is A$9.9m, which is last March plus 15%).

Data that would settle it. The contract and its revenue recognition (CFO). Whether any other deal of that kind is in the pipeline (VP Sales).

Solution options.

1. Report Software revenue growth (K3) with and without the largest licence, until the CFO says what it is (moves K3).
2. Ask the CFO to confirm how the licence is recognised, and whether annual subscriptions are booked in full at the start date (the ledger matches contract start dates), because that decides how repeatable the base is.
3. Ask the VP Sales and CFO to set the software target on repeat revenue (subscriptions and small perpetual deals), which grew 5% to 7%, rather than on total software.

Case 4: Design wins that ship (K4)

Clues. 31.5% of design wins old enough have shipped, against Marcus's belief of about 80%. It has been flat across the last four quarter-ends (30.8%, 31.4%, 31.7%, 31.5%). By design-win quarter, none of the first eight cohorts is above 39%. For the Jan to Jun 2023 cohort (430 wins, now 39 to 45 months old), the shipped share levels off at 32%. Of design wins at least 3 years old, 35% shipped, 6% were lost and 60% are still open.

Verdict. The shortfall against 80% is not new and is not explained by the bonus, the window, or missing dates: the ship rate has been about a third for every cohort we can see since Jan-23, and 80% was a belief that had never been measured. Observed Fact for the dated records; Working Hypothesis overall, because a third of the records have no dates. The CRM also holds a large pile of old design wins that are neither shipped nor lost (1,308 in the 18-month cohort, 60% of those 3 years old). Whether they are slow or dead is not recorded. Working Hypothesis. The bonus shows early signs of diluting what counts as a design win (more, smaller, earlier-lost) while the shipping rate has not moved. Effect on K4 so far: 0 pts of the 48.5 pt gap; the rest is unexplained by the data.

Data that would settle it. A reason for each lost or stalled design win. A product to SKU key between the CRM and the ERP, so shipping can be confirmed from invoices. The design-win dates for the undated records.

Solution options.

1. VP Sales runs a close-out review of the old open design wins: mark each shipped, lost or live, with a reason (moves K4 and the lost counter-metric).
2. VP Sales, CFO and the people team look at paying on pre-production or shipping, or adding a clawback, because the A$400 is paid at design win with no clawback (moves K4 and Design wins per quarter K4.2). The incentive is not a Stage 2 decision.
3. Reset the K4 target after the clean-up and the Q-11 window are agreed, using the measured baseline (a suggestion to Gary and the VP Sales).

Case 5: Forecast accuracy (K5)

Clues. Neither forecast has been within 5% since FY24-Q4: Finance was within 5% in 2 of 13 quarters, Sales in 0 of 12. The miss got worse after the hardware step in Jul-25: average miss before FY26-Q1 was 13.8% (Finance) and 14.8% (Sales); from FY26-Q1 it is 26.5% and 33.9%. Over the last 4 quarters (FY26-Q2, FY26-Q3, FY26-Q4, FY27-Q1) actual revenue was A$80.5m; Finance was too high by A$11.3m and Sales by A$27.6m.

Verdict. The forecasts are off for three stacked reasons. (1) Hardware, and the missed reset, is most of the dollars: 80% of Finance's four-quarter miss and 87% of Sales's. Same cause as Case 1. Strong Inference. (2) Sales has a standing upward bias of about 23%, present before the reset. The pattern is an Observed Fact; why is a Working Hypothesis (it fits a CRM that reps work to a bonus, but this data cannot test that). (3) Finance's latest forecast under-calls hardware by about 47% and is far from its own plan. Working Hypothesis. Software lumps add noise but little dollar error. The effects add up: hardware plus software plus other equals each source's total miss in the table. Unexplained: none by construction; the table splits each source's own miss.

Data that would settle it. How the Finance and Sales forecasts are built (the CFO and VP Sales, Q-5). Why the 26-Jun-26 Finance hardware forecast is half the 15-Jun-26 plan.

Solution options.

1. One forecast for Finance and Sales, built from installs and OEM stock (Case 1) and reviewed against a 'same as last quarter' benchmark each quarter (moves K5).
2. Report each forecast's bias with its accuracy, and correct Sales's forecast for its historic bias before it is used (moves K5).
3. CFO explains the gap between the FY27 plan and the 26-Jun-26 Finance forecast before K5 goes on page one.

5. Corrections to Gary's draft measures, and challenge notes

5a. Corrections (Before and After in full)

Measures confirmed as drafted: Software revenue growth (K3), Share of software revenue from the largest licences (K3.1), Gross margin %, last 12 months (K3.2) and Design wins per quarter (K4.2).

5b. Challenge notes

6. Data quality log

If more than 5% of a KPI's population is unmatched or missing, its baseline is labelled a Working Hypothesis. That applies to Design wins that ship (K4) only.

Files: 03 - Working Files/02_calculations.py, 02_results.json, 02_build_pack.py, spec.json (Kewpie's columns).

File: 2026.10.26 - Lumenwire Audio - 02 Challenge Notes.md

Lumenwire Audio: Challenge Notes from Stage 2

From Kewpie to Gary and Adam. 26-Oct-26. Sample data. Full evidence is in the KPI Calculation Pack. Kewpie has not added, dropped or reprioritised any KPI and has not changed a target. Each note is open until Gary or Adam answers it.

Corrections to Gary's draft measures

Challenge notes

File: 2026.10.26 - Lumenwire Audio - 02 Gary Response to Challenge Notes.md

Lumenwire Audio: Gary's Response to Kewpie's Challenge Notes

From Gary to Adam and Kewpie. 26-Oct-26. Sample data. This answers the 6 corrections and 15 challenge notes in 2026.10.26 - Lumenwire Audio - 02 Challenge Notes.md. I haven't changed the Business Requirements. Every change to a KPI, target or threshold below is a proposal waiting for Adam's sign-off. Every new target and threshold is my proposal, labelled Working Hypothesis, unless it says otherwise.

The short version. Kewpie's numbers test Marcus's story, which is what the dashboard is for. Three things he believed don't hold up: software growth is one licence, about a third of design wins ship (not 80%), and hardware fell mostly because OEMs stopped buying ahead of installs, not because end demand fell. My response keeps all five KPIs. I've proposed new targets where the old ones fail the Attainable test, and I've added "with and without the one-off licence" wherever that licence distorts the picture.

1. Corrections to my draft measures

All six are accepted. They change how a KPI is measured, not what it is or its target. Kewpie's Before and After text stands in full as written in the Challenge Notes.

2. Challenge notes

Total revenue, last 12 months, against the path to A$115m (K1)

C1: The FY27 board plan is already below the path. Accept, and Refer to the CFO. Reason: it doesn't make the threshold wrong. It shows the board's two numbers don't agree, which is how people get blindsided. Keep the A$115m path as the threshold, show the FY27 plan as a second line, and ask the CFO which one the board measures against (open questions Q-1 and Q-2).

C2: The FY27 plan repeats the one-off licence. Accept, and Refer to the CFO. Reason: a plan that counts an A$8.5m one-off twice overstates FY27. The board should see that.

C3: Volume rebates can pull hardware revenue into quarter-end months. Accept Kewpie's counter-metric. No new KPI. Reason: a rebate-rate tile would be an "accountant metric" with no owner action, and Marcus asked for none of those. Gross margin % is the counter-metric, and the quarter-end share goes in the calculation notes so Kewpie can watch for it. If it climbs above FY25's 46%, I'll bring it back as a sub-KPI.

New devices activated in the field (K2)

C4: The measure is only as good as the telemetry's coverage. Accept, and Refer to the Head of Platform Engineering (Q-4). Reason: this is exactly Marcus's condition. No change: K2 stays in the five, stays off page one, and keeps its target until Tomasz answers on coverage and the Jul-25 firmware.

Software revenue growth (K3)

C5: The +20% target fails the Attainable test because of one licence. Accept: change the headline. Refer the target to the VP Sales and CFO (Q-3). Reason: Marcus asked whether growth is "real and repeatable" and "how much comes from one big licence". A headline that includes a one-off A$7.4m licence can't answer that.

C6: Annual subscriptions may be booked in full at the start date. Refer to the CFO. Reason: it's a revenue recognition question, and only Finance can answer it. If the CFO confirms it, I'll propose a repeat-revenue measure, such as renewal rate on annual subscriptions, as a sub-KPI. That would be a new measure, so it would come back to Adam.

C7: The largest licence holds Share of software revenue from the largest licences (K3.1) at Red until Mar-27. Accept. Reason: a tile that sits Red for 5 months with nothing anyone can do is noise. Keep the threshold, but say why it's Red. The customer name stays off the board page (Q-7).

C8: The 77% target for Gross margin % (K3.2) differs from the board's 76%. Accept: align to the board's figure. Refer to the CFO to confirm. Reason: two margin targets on one page is the "whose number is right" problem Marcus wants fixed. The board's 76% (BT-03, Finance) is the stronger source.

Design wins that ship (K4)

C9: The 80% target fails the Attainable test (baseline 31.5%). Accept: reset the target. Refer to the VP Sales (with Q-11). Reason: 80% was Marcus's belief, never measured, and he said so. The oldest cohort levels off near a third. A target needing +5.4 points a month against a run rate of +0.08 is a wish, not a target.

C10: A third of CRM rows have no stage dates, and there's no product key to invoices. Accept, and Refer to the VP Sales and CFO. Reason: the data gap belongs in the Requirements, because the KPI can't be trusted without the fix. The baseline stays a Working Hypothesis.

C11: Reps are paid per design win with no clawback, and there are no reason codes. Accept: add the data request. Refer the incentive design to the VP Sales, CFO and People team. Reason: without a "reason lost" field, nobody can tell a real design win from one logged for the bonus. The bonus plan itself is outside this project.

Forecast accuracy (K5)

C12: Not yet one metric, and 5% is far from history. Accept. Refer the choice of forecast and the tolerance to the CFO (Q-5). Reason: neither forecast has been within 5% since FY24-Q4. I'll show both until the CFO picks one, and ease the starting target so it's hard but not hopeless. K5 stays off page one, as Marcus asked.

C13: Data problems in the forecast table, and Finance's hardware forecast is 52% below its own plan. Accept the data-load check. Refer the gap to the CFO. Reason: that gap is the clearest sign yet that Finance and Sales aren't working from one number. No KPI change.

OEM stock on hand (K2.1)

C14: Only 35 OEMs report, and there's no target or thresholds. Accept: rename and measure as months of cover. Refer the thresholds to the VP Sales. Reason: "top 40" is wrong. Months of cover answers Marcus's question better than raw units: are OEMs still sitting on stock, or about to reorder? This is a new measure, so it needs Adam's sign-off.

Design wins per quarter (K4.2)

C15: Design wins have risen since the bonus, with no change in the shipping rate. Accept. No change. Reason: this is why it sits under Design wins that ship (K4), not on top.

3. For Adam's sign-off

These change a KPI, target or threshold. None is in the Business Requirements yet.

1. Total revenue, last 12 months, against the path to A$115m (K1): add the FY27 plan as a second line in the threshold note (C1), and note in the target rationale that the plan repeats the one-off licence (C2)
2. Software revenue growth (K3): rename to "without one-off large licences", show the total alongside, start the target at "back to growth (0% or more)" and move the thresholds to match (C5)
3. Share of software revenue from the largest licences (K3.1): show it with and without the largest licence, and explain the Red in words until Mar-27 (C7)
4. Gross margin %, last 12 months (K3.2): target from 77% to the board's 76%, thresholds moved down 1 point (C8)
5. Design wins that ship (K4): target from 80% to 35% by Jun-27, thresholds 35 / 30 (C9)
6. Forecast accuracy (K5): target from 5% to 10%, thresholds 10 / 20, both forecasts shown until the CFO chooses (C12)
7. OEM stock on hand (K2.1): rename to "Months of stock cover at the OEMs that report", new measure, target 6 months or less, thresholds 6 / 9 (C14)
8. Business Requirements data notes: CRM date back-fill and a shared product key (C10), and a "reason lost" field request (C11)

Referred, no change needed now: CFO on C1, C2, C6, C8, C12 and C13; Head of Platform Engineering on C4; VP Sales on C9, C10, C11 and C14; People team on the bonus (C11).