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

Lumenwire Audio: KPI Calculation Pack

Stage 2 (KPI Development), Kewpie. Version 1.1, 26-Oct-26. Built from Business Requirements v1.1 (Adam approved Stage 2 and the eight changes to the targets, thresholds and measures on 26-Oct-26). Version 1.0 was built on Business Requirements v1.0.

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) is measured without the Mar-26 licence, so it is -15.6% and needs +1.7 pts a month to get back to 0%, while the run rate is -4.7 pts a month. Design wins that ship (K4) is 3.5 pts short of its 35% target: it needs +0.39 pts a month against a run rate of +0.08 pts.

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: Months of stock cover at the OEMs that report (K2.1)

Measure status: Corrected (divisor chosen: units invoiced; reels, free-text names, the number of reporters). Owner: VP Sales. Pending the Head of Platform Engineering and VP Sales.

• Plain English: Units of our parts the reporting OEMs hold, divided by the average monthly units we invoiced to those same OEMs in the same quarter. Units on hand are shown alongside.
• Calculation: cover(q) = SUM(units on hand at the OEMs that reported in q) / (SUM(qty invoiced to those OEMs in the 3 months of q) / 3), where units = units_on_hand x 500 for reel rows, otherwise units_on_hand. Calendar quarters.
• Divisor: units invoiced, not units activated. Same unit as the stock (parts, not finished devices). Full scale, with an OEM on every hardware line, where activations are a 1-in-10 sample with 7% of devices unassigned to an OEM. Stock is also what OEMs bought from us, so cover against purchases says how long they could stop buying. For comparison, units activated give 9.9 months in 2026-Q3 against 10.9 on invoices.
• 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; erp_invoice_lines.qty, oem_id, product_family (chip, module, card) for the divisor.
• Grain: OEM by quarter.
• Filters: 235 spellings of OEM names clean up to 35 OEMs, all matched to oem_master. 88 rows are reels of 500 (converted). 229 rows are finished goods containing our parts: kept, noted. Only the OEMs that reported in the quarter go into both the stock and the divisor, so a quarter with fewer reporters is not flattered.
• Baseline: 10.9 months in 2026-Q3 (841,883 units at 28 OEMs, buying 77,005 a month). Peak 15.4 months in 2025-Q3. Observed Fact for the reporters. Status: Red (6 months green, over 9 months red). Gary's draft quoted 9.3 months, my first estimate using every OEM that ever reported; the quarter's own reporters give 10.9.
• Pace needed: (6 - 10.9) / 3 quarters to Jun-27 = -1.6 months a quarter. Run rate (last 3 quarters): -0.7 months a quarter. Off pace, though improving.
• 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: Units on hand alone: 841,883 in 2026-Q3, 45% below the 2025-Q2 peak like for like. Cover fell because stock fell and purchases stayed low. Coverage is 46% of FY26 hardware revenue. 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 without one-off large licences, last 12 months against the year before (K3)

Measure status: Corrected (the one-off exclusion is now in the formula). 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, leaving out any single licence worth more than A$1m (threshold to agree with the CFO). Growth including those licences is shown alongside.
• Calculation: (SUM(software revenue, R12M) - SUM(licences over A$1m started in R12M)) / (SUM(software revenue, prior R12M) - SUM(licences over A$1m started in prior R12M)) - 1. Software revenue = -1 x SUM(gl_monthly.amount_aud) for accounts 4100 and 4110. The licences left out come from software_licences.contract_value_aud by start_date.
• Sources and why: gl_monthly (the P&L); software_licences to find the large licences. The licence table equals the ledger within A$27k in any month and A$13k over FY26, so removing a licence at its contract value removes it from the ledger month it was booked in. 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; sign flipped; latest complete month Sep-26; single licences over A$1m left out of both windows.
• Baseline: -15.6% for the 12 months to Sep-26 (A$17.7m against A$21.0m). 1 licence over A$1m in the current window (A$7.4m, signed 2026-03-27) and 0 in the prior window. Including it: +19.7%. FY26 on the same rule is -1.6% (headline FY26 growth was +38.2%, reproducing Marcus's 38%). Observed Fact. Status: Red (0% green, -10% red line).
• Pace needed: (0% - (-15.6%)) / 9 months to Jun-27 = +1.7 pts a month. Run rate (last 3 months): -4.7 pts a month (-1.6%, -19.8%, -16.6%, -15.6%). Off pace, and going the wrong way. Software without the licence runs at A$1.48m a month now.
• 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%.
• 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 (Q-7). The next largest licence in the window is A$864k, so any cut-off between A$0.9m and A$7.4m gives the same answer.

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: Green (76% green, 74% red line).
• Pace needed: the target is now 76% (the board's FY27 figure), and 76.5% already meets it, so no lift is needed (-0.06 pts a month). Run rate: -0.17 pts a month. Without the Mar-26 licence margin is 74.1%, which reads Amber; the figure falls to that in Mar-27 when the licence leaves the window, 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: Amber (35% green, 30% red line).
• Pace needed: (35% - 31.5%) / 9 months to Jun-27 = +0.39 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. Off pace, but close: the target is 3.5 pts away.
• 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: Amber for Finance and Red for Sales (10% green, 20% red line).
• Pace needed: within 10% by FY27-Q4 (3 more quarters): Finance -2.4 pts a quarter from 17.2%; Sales -5.2 pts a quarter from 25.6%. 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) ................................ Amber
  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  Months of stock cover at the OEMs that report ............ Red
O2  Keep software growing, with gross margin holding up
    K3  Software revenue growth without one-off large licences ........ Red
        K3.1  Share of software revenue from the largest licences ...... Red
        K3.2  Gross margin %, last 12 months ........................... Green
O3  Keep design wins turning into shipping products
    K4  Design wins that ship .......................................... Amber
        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 10.9 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: 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).