Technical report

The stakeholder report’s own eight questions, restated as a technical review

The case description is answered two ways. The stakeholder report answers it in plain language, in Henrik Malm’s own question order, with confidence stated in words and no method named. This page is the same engagement, the same 3y_baseline run, and the same eight questions, restated the way a technical review expects: model specifications, coefficient tables with HAC-robust standard errors, confidence intervals, and diagnostics, in place of the stakeholder report’s narrated conclusions. Nothing here is a different analysis, it is the working behind that one, made explicit.

Every regression below uses the identical cleaning rule, window, and covariate set as analysis_notebook.py (the notebook the stakeholder report is built from), restated with statsmodels in place of the notebook’s raw np.linalg.lstsq, so every coefficient carries a standard error and a confidence interval instead of a bare point estimate. One claim, in Section 3, is additionally checked directly against this run’s own hidden ground truth, not just restated more formally, per Checking ground truth. Every figure is plotly, interactive, and its own “Show the code” also carries the chart-building code, not just the model, collapsed by default so it doesn’t get in the way of reading.

1 · Where the money actually goes

Every distinct row on a receipt is grouped by its full identity (product, price, quantity, till, hour, payment type), and a receipt whose every distinct row repeats an even number of times is flagged: a POS retry re-posts a whole transaction byte-identical, so a genuine sale’s rows essentially never come out all-even by chance.

full_key = [
    "receipt_id", "hour", "payment", "customer_id", "uid",
    "qty", "unit_price", "promo", "date", "ref_receipt_id",
]
counts = receipts_raw.groupby(full_key, dropna = False).size().reset_index(name = "n")
is_retry = counts.groupby("receipt_id")["n"].apply(lambda s: (s % 2 == 0).all())
counts["is_retry"] = counts["receipt_id"].map(is_retry)
counts["qty_clean"] = np.where(
    counts["is_retry"],
    counts["qty"] * (counts["n"] // 2),
    counts["qty"] * counts["n"],
)
group_cols = ["receipt_id", "hour", "payment", "customer_id", "uid", "unit_price", "date", "ref_receipt_id"]
receipts = counts.groupby(group_cols, dropna = False)["qty_clean"].sum().reset_index(name = "qty")
n_flagged = int(counts.loc[counts["is_retry"], "receipt_id"].nunique())
print(f"{n_flagged} receipts flagged")
# -> 105 receipts flagged

# grade the flag against this run's own hidden answer key
hidden_imp = pd.read_csv(f"{HIDDEN}/imperfections.csv")
true_dup_receipts = set(hidden_imp.loc[hidden_imp["kind"] == "dup_receipt", "key"].astype(int))
blind_flagged = set(counts.loc[counts["is_retry"], "receipt_id"].unique())
print(f"true: {len(true_dup_receipts)}, false positives: {sorted(blind_flagged - true_dup_receipts)}")
# -> true: 103, false positives: [10091, 32061]

105 receipts are flagged, and the hidden answer key for this run says 103 dup_receipt defects were actually planted. The two extras are not detector error in any troubling sense, Section 1’s own residual-tracing step (below) independently identifies both of them as genuine single-item double-scans, a different, real defect pattern that the all-even rule cannot distinguish from a re-upload on receipt content alone. The blind detector’s false-positive set and the independently traced double-scans are, exactly, the same two receipts.

Year Till revenue (cleaned) Ledger revenue Gap
2025 €742,972.23 €742,977.12 −€4.89
2026 €771,304.01 €771,317.41 −€13.40
2027 €814,278.03 €814,278.03 €0.00 
lines = receipts_raw.groupby(
    ["receipt_id", "date", "uid", "qty", "unit_price"],
).size().reset_index(name = "n_dup")
distinct = lines.groupby("receipt_id").size().rename("n_distinct")
lines = lines.join(distinct, on = "receipt_id")
# a genuine double-scan: exactly one distinct item on the receipt, appearing twice
suspects = lines[(lines["n_distinct"] == 1) & (lines["n_dup"] == 2)].copy()
suspects["true_value"] = (suspects["qty"] * suspects["unit_price"]).round(2)
gaps = [4.89, 13.40]   # the two residual gaps above
found = suspects[suspects["true_value"].isin(gaps)]
print(found[["receipt_id", "date", "uid", "unit_price"]])
# -> receipt 10091 (2025-07-31, SF-SHL-009, 4.89) and
#    receipt 32061 (2026-11-21, HC-CAG-003, 13.40) match exactly

Both residual gaps trace to a single receipt each: a one-item receipt scanned in two identical lines, at exactly the value of that year’s gap. The till-to-ledger reconciliation closes exactly, with a named cause for every euro, not an unexplained rounding difference.

2 · Am I really growing, or does it just feel that way?

\[ \log(\text{revenue}_t) = \beta_0 + \beta_1 t + \sum_{k=2}^{12} \gamma_k\,\mathbb{1}[\text{month}_t = k] + \varepsilon_t \]

OLS on log monthly revenue, a linear trend plus eleven month dummies (January the reference month), HAC-robust standard errors (3 lags, monthly data). January 2025 is excluded from the fit, per the case description, the owner’s own account is that the opening month was pantry-filling, not ordinary trade.

train = monthly[monthly["t"] != 1].copy()
X = sm.add_constant(pd.concat(
    [train[["t"]], month_dummies(train["mm"])],
    axis = 1,
))
y = np.log(train["rev"])
trend_model = sm.OLS(y, X).fit(
    cov_type = "HAC",
    cov_kwds = dict(maxlags = 3),
)
trend_pct_yr = (np.exp(trend_model.params["t"] * 12) - 1) * 100
print(trend_model.summary().tables[1])
print(f"annualized: {trend_pct_yr:.2f}%")
# -> t coef 0.00369 (se 0.00058, p<0.001). annualized +4.53%

# the chart: actual monthly revenue against the fitted trend + season
fig = go.Figure()
fig.add_trace(go.Bar(
    x = train["t"],
    y = train["rev"],
    marker = dict(color = MUTED),
    name = "actual monthly revenue",
))
fig.add_trace(go.Scatter(
    x = train["t"],
    y = np.exp(trend_model.fittedvalues),
    mode = "lines",
    line = dict(color = BLUE, width = 2),
    name = "trend + season (fitted)",
))
fig.update_yaxes(title = "revenue (EUR/month)")
fig.update_xaxes(title = "month (Feb 2025 = 2)")
takeaway(fig, f"net of season, growth ≈{trend_pct_yr:+.1f}%/year")
savefig(fig, "02_trend_season", title = "Monthly revenue: fitted trend + seasonal OLS (HAC SEs)")
Term Coefficient HAC SE \(p\)
trend (\(t\), monthly log) 0.00369 0.00058 <0.001
annualized +4.53% 95% CI [+3.10%, +5.97%]

\(n = 35\), \(R^2 = 0.724\). The month dummies (not shown in full) are jointly responsible for most of the fit, only February, September, November, and December are individually significant at 5%, consistent with a real but moderate seasonal cycle rather than a dominant one.

2025 → 2027
Units sold +6.3%
Average shelf price +3.1%
Basket size (€/trip) +7.1%
Shopping trips +2.3%

Growth is real, not a pricing artifact, units grew roughly twice as fast as price. It concentrates in basket size rather than trip count: existing visits carrying more per trip, not a larger number of visits.

3 · The shrinkage, and whether it’s theft

dupe = procurement.groupby(
    ["uid", "qty", "unit_cost", "order_date", "delivery_date"],
).size().reset_index(name = "n")
dupe = dupe[dupe["n"] > 1].copy()
dupe["delivery_month"] = dupe["delivery_date"].str.slice(0, 7)
dupe["extra_units"] = (dupe["n"] - 1) * dupe["qty"]
print(dupe[dupe["delivery_month"] == "2027-08"]["extra_units"].sum())
# -> 538

# grade "no theft" directly: this run's own hidden defect-family log
hidden_imp = pd.read_csv(f"{HIDDEN}/imperfections.csv")
print(hidden_imp["kind"].value_counts().to_dict())
print("theft-labeled family present:", hidden_imp["kind"].isin(["theft", "shrinkage_theft"]).any())
# -> {'payment_variant': 618, 'unrecorded_spoilage': 527, 'void_pair': 309,
#     'hour_glitch': 206, 'dup_receipt': 103, 'snapshot_typo': 72,
#     'dup_invoice': 70, 'missing_invoice': 18, 'weather_outage': 9,
#     'category_typo': 2}
# theft-labeled family present: False

# the chart: write-offs by reason, at invoice cost
reason_labels = dict(
    spoilage = "spoiled on the shelf",
    stock_count = "month-end count correction",
    damage = "the freezer accident",
)
fig = go.Figure(go.Bar(
    x = [reason_labels[r] for r in by_reason.index],
    y = by_reason["eur"].tolist(),
    marker = dict(color = [RED if r == "damage" else BLUE for r in by_reason.index]),
    text = [f"€{v:,.0f}" for v in by_reason["eur"]],
    textposition = "outside",
    textfont = dict(color = INK, size = 12.5),
))
fig.update_yaxes(
    title = "EUR over 3 years",
    range = [0, float(by_reason["eur"].max()) * 1.2],
)
takeaway(fig, f"{total_eur / rev_3y * 100:.1f}% of revenue, almost all spoilage")
savefig(
    fig, "03_writeoffs", title = "Write-offs by reason, at invoice cost",
    showlegend = False, height = 420, hide_value_axis = True,
)
Reason Units € (at invoice cost)
Spoilage 73,144 €118,830.63
Stock-count correction 2,270 €4,984.55
Damage (freezer incident) 960 €1,230.21
Total €125,045.39 (5.37% of 3-year revenue)

The stock-count correction line is where a theft signal would show up, if one existed. Its largest single month (2027-08, 462 units) traces almost entirely to a paperwork cause: 538 units’ worth of supplier deliveries posted twice that month (same product, quantity, cost, and dates, entered under two different posting dates).

This is the one claim on this page checked directly against ground truth rather than restated more formally. This run’s hidden answer key lists ten defect families actually planted in the paperwork, none of them theft or unexplained shrinkage. Every discrepancy in this run’s records is a documented data-entry or dedup artifact. “No theft signal” is not just a well-argued inference here, it is confirmed against the generating mechanism.

4 · What did Spara+ actually cost me?

Pre-entry trend and seasonal model (Section 2’s specification, fit only on \(t \in [2, 26]\), February 2025 through February 2027), projected forward to March–December 2027 and compared against what actually happened.

train4 = monthly[(monthly["t"] >= 2) & (monthly["t"] <= 26)]
post4 = monthly[monthly["t"] >= 27]
X_ = sm.add_constant(pd.concat(
    [train4[["t"]], month_dummies(train4["mm"])],
    axis = 1,
))
rev_model = sm.OLS(np.log(train4["rev"]), X_).fit(
    cov_type = "HAC",
    cov_kwds = dict(maxlags = 3),
)
Xp = sm.add_constant(
    pd.concat([post4[["t"]], month_dummies(post4["mm"])], axis = 1),
    has_constant = "add",
)
pred_rev = np.exp(rev_model.predict(Xp))
print(
    f"predicted {pred_rev.sum():,.0f}, actual {post4['rev'].sum():,.0f}, "
    f"gap {post4['rev'].sum() - pred_rev.sum():,.0f}"
)
# -> predicted 683,751, actual 683,786, gap +35

# the chart: actual vs. pre-entry-trend-predicted revenue
fig = go.Figure()
fig.add_trace(go.Scatter(
    x = post4["t"], y = pred_rev, mode = "lines",
    line = dict(color = MUTED, width = 2, dash = "dash"), name = "expected (pre-entry trend)",
))
fig.add_trace(go.Scatter(
    x = post4["t"], y = post4["rev"], mode = "lines+markers",
    line = dict(color = BLUE, width = 2), name = "actual",
))
fig.update_yaxes(title = "revenue (EUR/month)")
fig.update_xaxes(title = "month (March 2027 = 27)")
takeaway(fig, f"10-month gap ≈ €{gap_rev:+,.0f}, not distinguishable from noise")
savefig(fig, "04_competitor", title = "Actual vs. pre-entry-trend-predicted revenue since the competitor opened")
Quantity Value
Predicted revenue, Mar–Dec 2027 €683,751
Actual revenue €683,786
Gap +€35
Gap, units +0.47%
Gap, trips +2.25%
Pre-period fit \(n=25\), \(R^2=0.737\)

A €35 gap against a €684k base is indistinguishable from zero at any useful precision. Units and trips both land close to their pre-entry trend too. Nothing in the aggregate top line shows a step down when the competitor opened.

A second design checks the categories the owner specifically discounted in response (drinks, snacks, household goods) against everything else, a difference-in-differences around his May 2027 price cut:

\[ \log(\text{revenue}_{ct}) = \beta_0 + \beta_1 t + \beta_2\,\text{exposed}_c + \beta_3\,\text{post}_t + \beta_4\,(\text{exposed}_c \times \text{post}_t) + \sum_k \gamma_k\,\mathbb{1}[\text{month}_t=k] + \varepsilon_{ct} \]

Xd = sm.add_constant(pd.concat(
    [cat_monthly[["t", "exposed_i", "post", "did"]], month_dummies(cat_monthly["mm"])],
    axis = 1,
))
did_model = sm.OLS(np.log(cat_monthly["rev"]), Xd).fit(
    cov_type = "HAC",
    cov_kwds = dict(maxlags = 4),
)
print(did_model.params["did"], did_model.pvalues["did"])
# -> coefficient -0.0213 (p=0.274)
Term Coefficient (\(\beta_4\)) 95% CI \(p\)
exposed × post (DiD) −2.11% [−5.79%, +1.71%] 0.274

Not statistically distinguishable from zero, \(n=72\). This design cannot actually clear the competitor either way, the owner’s own price cut is confounded with the categories being tested, so “no detectable effect” here is genuinely uninformative rather than reassuring. The top-line result in the table above is the one worth trusting. This one is reported for completeness and its own honest limitation.

5 · Was the expansion worth it?

The cost side is a direct ledger sum over the 14 months since the November 2026 hire, no model required. The benefit side reuses Section 4’s trend-projection design (fit on \(t \in [2,22]\), projected to \(t \geq 23\)) to isolate the revenue lift actually attributable to the extra hours, rather than crediting the expansion with revenue the shop’s own pre-existing growth would have produced anyway.

post5 = cs[cs["t"] >= 23]
train5 = cs[(cs["t"] >= 2) & (cs["t"] <= 22)]
pred_rev5, rev_model5 = fit_and_project_cs(train5, post5, "revenue")
extra_rev = float(post5["revenue"].sum() - pred_rev5.sum())
gm = 1 - float(cs["procurement"].sum()) / float(cs["revenue"].sum())
wage_bill = float(post5["wages"].sum() + post5["payroll_tax"].sum())
print(
    f"extra revenue {extra_rev:,.0f}, at margin {gm:.1%}, "
    f"extra gross profit {extra_rev * gm:,.0f}, wage bill {wage_bill:,.0f}, "
    f"revenue needed to cover it {wage_bill / gm:,.0f}"
)
# -> extra revenue 20,248, at margin 16.3%, extra gross profit 3,295,
#    wage bill 65,900, revenue needed to cover it 404,961

# the chart: cost/benefit waterfall
waterfall_values = [extra_gross_profit, -wages, -payroll, -extra_util, -capex]
fig = go.Figure(go.Waterfall(
    x = ["extra gross profit", "wages", "payroll tax", "extra utilities", "fit-out"],
    measure = ["relative"] * 5,
    y = waterfall_values,
    text = [f"{'+' if v >= 0 else ''}{v:,.0f}" for v in waterfall_values],
    textposition = "outside",
    textfont = dict(color = INK, size = 12.5),
    connector = dict(line = dict(color = MUTED, width = 1)),
    increasing = dict(marker = dict(color = BLUE)),
    decreasing = dict(marker = dict(color = RED)),
))
fig.update_yaxes(title = "EUR", range = [net * 1.15, extra_gross_profit * 3])
takeaway(fig, f"net so far: ≈€{net:,.0f}", x = 0.98, y = 0.9, color = RED, anchor = "right")
savefig(
    fig, "05_expansion", title = "Expansion cost/benefit waterfall",
    showlegend = False, hide_value_axis = True,
)
Line €
Wages (Ana, 14 months) 52,720
Payroll tax 13,180
Extra utilities (attributable) 2,245
Fit-out (one-time) 14,000
Total cost 82,145
Extra revenue vs. pre-expansion trend 20,248
Gross margin 16.27%
Extra gross profit 3,295
Net, to date −78,850

Pre-period fit: \(n=21\), \(R^2=0.733\). At the shop’s realized margin, covering the wage bill alone (€65,900) requires roughly €404,961 of genuinely new revenue, about twenty times what the extended hours have actually produced so far. The shortfall is a margin-arithmetic result, not a modeling artifact, a fixed wage is a full euro of cost every month, and a euro of extra revenue keeps only about sixteen cents of it.

6 · Which customers am I losing, and who replaced them?

Card tokens with at least 10 receipts across the three years are counted as regulars (\(n=289\)), and a token silent for 90 or more days as of a given year-end is counted as gone quiet. Both cutoffs are stated, not hidden, so the sensitivity of the count to them is checkable.

card_sales = sales[sales["customer_id"].notna() & sales["ref_receipt_id"].isna()]
visits = card_sales.groupby("customer_id").agg(
    n = ("receipt_id", "nunique"),
    first = ("date", "min"),
    last = ("date", "max"),
)
regulars = visits[visits["n"] >= 10].copy()
regulars["first_dt"] = pd.to_datetime(regulars["first"])
regulars["last_dt"] = pd.to_datetime(regulars["last"])

rows = []
for year_end, label in [("2025-12-31", 2025), ("2026-12-31", 2026), ("2027-12-31", 2027)]:
    ye = pd.Timestamp(year_end)
    eligible = regulars[regulars["first_dt"] <= ye]
    silent = eligible[(ye - eligible["last_dt"]).dt.days >= 90]
    new_that_year = regulars[regulars["first_dt"].dt.year == label]
    rows.append(dict(
        year = label,
        regulars_established_by_year_end = int(len(eligible)),
        gone_quiet_90d_plus = int(len(silent)),
        newly_established_that_year = int(len(new_that_year)),
    ))
churn_table = pd.DataFrame(rows)
print(churn_table)

# the chart: new regulars vs. regulars gone quiet, by year
fig = go.Figure()
fig.add_trace(go.Bar(
    x = churn_table["year"], y = churn_table["newly_established_that_year"],
    name = "newly established", marker = dict(color = BLUE),
    text = churn_table["newly_established_that_year"], textposition = "outside",
))
fig.add_trace(go.Bar(
    x = churn_table["year"], y = -churn_table["gone_quiet_90d_plus"],
    name = "gone quiet 90d+ (cumulative)", marker = dict(color = RED),
    text = churn_table["gone_quiet_90d_plus"], textposition = "outside",
))
fig.update_yaxes(title = "customers (tokens)")
takeaway(fig, "a flow, not a leak: new faces roughly keep pace with the quiet ones", x = 0.5, y = 0.85)
savefig(fig, "06_churn", title = "New regulars vs. regulars gone quiet, by year", hide_value_axis = True)
Year Regulars established (cumulative) Gone quiet (90d+, cumulative) Newly established that year
2025 264 9 264
2026 281 20 17
2027 289 48 8

By end-2027, 48 of 289 regulars (16.6%) have gone quiet 90 or more days, while the regular count still grew net across all three years. This is a descriptive panel count, not a survival model, and it carries a genuine right-censoring caveat: a regular who went quiet in the final weeks of 2027 cannot yet be distinguished from one who will return, so the 2027 figure is a plausible slight overstatement of true permanent departures.

7 · What should I expect 2028 to look like?

\[ \log(\text{revenue}_t) = \beta_0 + \beta_1 t + \beta_2\,\text{post-expansion}_t + \sum_{k=2}^{12} \gamma_k\,\mathbb{1}[\text{month}_t=k] + \varepsilon_t \]

Same trend-and-season specification as Sections 2 and 4, with an added structural-break indicator from the November 2026 expansion, fit on the full history from \(t=2\) onward and projected twelve months forward. The 80% interval uses the in-sample HAC residual standard deviation.

X7 = sm.add_constant(pd.concat(
    [train7[["t", "post_ind"]], month_dummies(train7["mm"])],
    axis = 1,
))
fc_model = sm.OLS(np.log(train7["rev"]), X7).fit(
    cov_type = "HAC",
    cov_kwds = dict(maxlags = 3),
)
sigma7 = float(np.sqrt(fc_model.mse_resid))
point_log = fc_model.predict(Xf)   # Xf: t=37..48, post_ind=1
pred28 = np.exp(point_log)
lo28 = np.exp(point_log - 1.2816 * sigma7)
hi28 = np.exp(point_log + 1.2816 * sigma7)
naive_wmape = np.abs(rev2027 - rev2026).sum() / rev2027.sum()
print(
    f"point {pred28.sum():,.0f}, range [{lo28.sum():,.0f}, {hi28.sum():,.0f}], "
    f"naive WMAPE {naive_wmape:.1%}"
)
# -> point 835,912, range [783,474, 891,859], naive WMAPE 7.8% vs model 3.1%

# the chart: 2028 forecast against an 80% interval
fig = go.Figure()
fig.add_trace(go.Scatter(
    x = list(future["t"]) + list(future["t"][::-1]),
    y = list(hi28) + list(lo28[::-1]),
    fill = "toself", fillcolor = "rgba(42,120,214,0.12)", line = dict(width = 0),
    showlegend = False, hoverinfo = "skip",
))
fig.add_trace(go.Scatter(
    x = monthly[monthly["t"] >= 25]["t"], y = monthly[monthly["t"] >= 25]["rev"],
    mode = "lines", line = dict(color = MUTED, width = 2), name = "actual (2027)",
))
fig.add_trace(go.Scatter(
    x = future["t"], y = pred28, mode = "lines+markers",
    line = dict(color = BLUE, width = 2), name = "2028 forecast",
))
fig.update_yaxes(title = "revenue (EUR/month)")
fig.update_xaxes(title = "month (Jan 2027 = 25)")
takeaway(fig, f"point €{pred28.sum()/1000:,.0f}k, range €{lo28.sum()/1000:,.0f}k-€{hi28.sum()/1000:,.0f}k", y = 0.15)
savefig(fig, "07_forecast", title = "2028 revenue forecast with an 80% interval, structural break at the expansion")
Quantity Value
2028 revenue, point forecast €835,912
2028 revenue, 80% interval [€783,474, €891,859]
In-sample WMAPE (this model) 3.08%
In-sample WMAPE (seasonal-naive baseline) 7.80%
\(R^2\) 0.737, \(n=35\)
2028 profit-before-tax, at 2027’s cost structure €2,426, range [−€4,621, +€9,945]

The model tracks its own recent history roughly 2.5× tighter than a seasonal-naive baseline (repeat last year), which is why its interval is trusted over a flat guess. Converted to profit at 2027’s realized cost structure, the range straddles zero: a small profit and a small loss are about equally likely if nothing about staffing or the lease changes.

8 · Renew, close, or change something?

rent_2026 = float(cs.loc[cs["year"] == 2026, "rent"].iloc[0])
rent_2027 = float(cs.loc[cs["year"] == 2027, "rent"].iloc[0])
print(
    f"{(rent_2027 / rent_2026 - 1) * 100:.1f}% increase, "
    f"{(rent_2027 - rent_2026) * 12:,.2f} extra cost per year"
)
# -> 12.0% increase, 1,671.35 extra cost per year
What changed in 2027 Estimated effect on that year’s profit
Rent review (contractual, +12% from January) −€1,671
Competitor entry, Section 4 +€35 (statistically indistinguishable from zero)
November 2026 expansion, Section 5, annualized ≈ −€70,410/year

Sections 4 and 5 together account for the year’s result: a real capital decision costing roughly seventy thousand euros a year against a thin margin, next to a competitor whose measurable top-line effect is indistinguishable from noise. The rent review is a rounding error by comparison.

Reproducing this

Every code block above is a real excerpt of one script, run against the same 3y_baseline visible/ data analysis_notebook.py uses, writing every number into a results.json alongside it and every figure as both a static PNG and the interactive HTML embedded above. The one exception, Section 3’s hidden-answer-key check, additionally reads this run’s own hidden/imperfections.csv, once, only to grade an already-made claim. The full script is here: technical-report/analysis.py.

This page and the stakeholder report are the same engagement told twice: one is what you hand the client, the other is what backs it up before it goes out the door. For a page that is deliberately not part of this engagement, a standalone stress test of what the package’s output can support beyond an ordinary client engagement, see the advanced methods demonstration.