Follow the margin

One helper, lib.monthly, returns revenue, cost, profit, margin, orders, lines, units and identified customers per month, for the whole frame or for any list of keys. Every long series in the track comes out of it, so the definition of "a month of margin" lives in one place. Two rules ride along. Load with dedupe=True, because a1 found S02 duplicating lines in 2021-H1. And never chart the partial current month as a value: the dataset ends 2026-09-07, so September 2026 has a week of orders, and a week drawn next to full months looks like a collapse.

Read the whole before the parts. Revenue climbs, the Q4 peaks repeat, and the blended margin slides a few points from 2024. Nothing here says crisis, and a chairman who sees only this chart is right to feel calm. The next chart takes the calm away with the same numbers.

Same helper, one extra key. Ten panels, shared axes so the eye compares heights honestly, key servers in amber, a faint dashed line at March 2024 on every panel so the reader can see that eight of them do nothing there. Shared y-limits are the whole trick: let matplotlib autoscale each panel and every server looks like it has a dramatic story.

lib.annotate_events draws every row of known_events as a thin dashed line with a short label - amber for business events, faint for technical ones. It goes on every long series, not just the one where you expect a bend, for a plain reason: the first thing a reader does when a line bends is ask "what happened there?", and an analyst who has to look it up loses the room. The team's memory is data. Printwell keeps nine rows of it, which a1 filed as a gap; until there is a real event log, those nine lines are the best context the company has, and they belong on the chart rather than in a footnote.

Two habits make the overlay honest. Filter by scope when a chart is about one server, using scope_filter, so platform-wide events and that server's events show and other servers' events do not. And never let an overlay do the arguing: the line marks a date, the bridge in Part 3 names the mechanism, and only the two together make a claim.

Index every series to the average of September 2023 through February 2024 = 100. Indexing puts orders, revenue and profit on one axis so the reader sees them diverge; the six-month base smooths a single odd month out of the denominator. Shade March 2024 so the eye lands where the story starts.

Print the three-month comparison as a table under the chart. A chart persuades; a table of four rows is what gets pasted into the email that follows. Both come from the same key frame, so they cannot disagree.

Take the S07 margin series as of August 2024, five months after the break, and draw it three times: the last three months, the last twelve, the full history. Same numbers, same axis limits. The three-month view is a wobble around 29. The twelve-month view is a step. The full view is a cliff with four flat years in front of it. Anyone running the business off a trailing-quarter dashboard in 2024 saw the first panel and was right, from inside that window, to see nothing.

Now do it yourself, on the real monthly numbers the notebook exports. The widget below draws the course dataset, not a model. Change data-series to S08, S03 or platform in the page source to repeat the exercise on a second hit, a null server and the blend.

Printwell's revenue by month of year, averaged over the five complete years 2021-2025 and indexed to 100: Q4 carries the year and February is the trough. This chart exists so that two mistakes cannot be made later. Nobody credits a Q4 initiative for a Q4 peak that happens every year, and nobody blames a February dip on a January decision. It also explains the volume term of the bridge in Part 3: comparing Sep-Feb with Apr-Sep bakes in a seasonal difference, and the same difference shows up on the servers that had no decision, which is how you know it is season and not the decision.

The tempting shortcut is a blended bridge: average price per unit and average cost per unit for each period, times units. It is quick and it is wrong in a specific way. If price and cost effects are computed on blended rates, then volume + price + cost equals the whole profit change by construction, and mix comes out as exactly zero every time. A term that is zero by algebra is not a finding; it is a column you forgot to compute. lib.margin_bridge computes price and cost per SKU, over the SKUs sold in both periods, at period-b units, and lets mix be the remainder: composition shifts and SKUs that appear in only one period. On S07 and S08 mix is +5k, small but real, which is what a mix term is supposed to look like when nothing happened to mix.

Price did nothing, mix did little, volume was seasonal and moved the same way on both groups. Cost is the term, and it is confined to two servers. known_events has a candidate dated 2024-03-01. The bridge does not prove the event caused the cost; it proves that whatever happened was a cost change and not a demand change, which rules out most of the explanations the room will offer.

The bridge needs you to choose the periods, and choosing them with the event date in hand is a small circularity. So run a detector that has never heard of March 2024: the month-over-month change in margin per server, standardised against the trailing twelve months of its own changes, shifted one month so the month under test does not sit in its own baseline. A step shows as one large negative z followed by nothing, because after the step the changes are small again.

The detector is validated on its nulls as much as its hits. Eight servers took no decision, and eight servers produce no spike beyond noise - that is what makes the two amber spikes evidence rather than decoration. A detector that fires everywhere is a random number generator with a title. The one extra hit it does raise, S02 in 2021-03, is the duplicate-load defect from a1 leaking into margin, which is a second correct answer, not a false alarm.

Before trusting a cost story, read the raw lines. Pull fifty rows from S07 after March 2024 and fifty from before, same SKUs where you can, and look at unit_cost with your own eyes. Ask what it actually is. In many warehouses "unit cost" is a live supplier cost that changes when the supplier does; in many others it is a standard cost re-allocated once a year by finance, and a step in it means an accounting decision, not a fulfilment one. The bridge cannot tell those apart. Fifty rows and one question to whoever owns the column usually can.

a1 already filed the answer for Printwell: cost is a unit constant per SKU in dim_product, so the 2024 step is a change to what the platform books per unit, and there is no fulfilment cost per order anywhere in the data. That is why c3 recommends collecting one. Reading rows is how you find out what your aggregate is made of; it takes ten minutes and it has saved more analyses than any model.

State the assumption in the caption and the chart title, every time: this is what profit would have been had the margin held, and holding the margin is exactly the thing in question. Whether the cost change also cost customers is a different question with a different method - a5 tests it with cohorts and finds the repeat rate on these servers fell two quarters later - so the 251k is a floor, not an estimate of total damage, and the page says so. Revenue on the key servers went 686k in 2023 to 884k in 2024 to 765k in 2025; profit 290k to 224k between 2023 and 2025. Growth and loss at the same time is why nobody noticed.

The lookback widget on this page and on c1 draws real monthly numbers, and those numbers come from this notebook. Build a plain dict of lists per series, round the values so the file is small, and serialise with json.dumps. Never assemble JSON by string concatenation: one unescaped quote or a stray NaN produces a file that is invalid JavaScript, the widget silently renders nothing, and the page looks like the export never ran. A serialiser fails loudly at write time, which is where you want it to fail.

The same cell writes reports/a2_server_year_summary.csv, the server-by-year table c2 reads. Every number a chairman page quotes traces back to a file a notebook wrote, so a rerun of the notebook updates the page and a retyped number is impossible.