What has been recorded, and for how long

Start with the source you already expect, and ask it in her words. The bank's question g09 is "Which systems does one sale touch, and how far back do they go?", and its teach-back goes straight after: "History is what a model learns from. Three years of daily sales is a lot; one year is not." She knows the answer without knowing why it matters: the till, the POS, per product per outlet, daily, three years back. She may add, because it annoys her, that the product codes are different in Singapore and Malaysia.

Then ask the question a scientist most needs and most often skips, g11: "Is there any record of past stock levels, or only of sales?" Say its teach-back out loud: "A model that predicts stock-outs needs to have seen stock-outs. If nobody recorded them, the first project is recording them." At Harbourline the answer is the one that changes the project. There is no stock history at all. Outlet managers type a count into a shared spreadsheet on Fridays, three versions of it are in circulation, and each Friday's count is typed over the last. Last week's stock level does not exist anywhere.

The third shape takes no question of its own, because it falls out of the second: nobody records a stock-out. A pharmacist sees an empty shelf and WhatsApps the area manager; a patient who found it empty calls, and the call reaches Adeline. That call is the only trace, roughly 30 a month across 38 outlets, and it is written down nowhere. So the three shapes are recorded by a machine, typed by a person and overwritten, and absent. Only the first has a past a model could learn from, and it is the wrong row.

The tempting move is to reconstruct stock-outs from the sales. It fails for a reason you can explain to her in a sentence: a day with no sales means two different things. Either nobody came in wanting the product, or somebody did and the shelf was empty. The till writes the same zero for both. A model trained on sales learns what people bought, not what they would have bought, and the gap between the two is exactly the stock-out she is trying to stop.

Sales history is still worth having. It is a feature, and a strong one: it says how fast each of the 40 chronic-medication products moves in each outlet. It is not a label. The label, the row that says "this outlet, this product, this day, the shelf was empty", has to be written down by somebody on the day it happens, and nobody does. That sentence, said in the meeting, is the difference between promising a model and promising a log.

Two sources are usually run together into one number, and they should not be. In 2014 Steve Lohr reported in The New York Times that data scientists spend 50 percent to 80 percent of their time collecting and preparing data before it can be explored. In 2016 CrowdFlower's data science survey reported that respondents spent 60 percent of their time cleaning and organising data and a further 19 percent collecting it. Different methods, different shapes of answer: one a range for collecting and preparing together, the other two separate figures. Quote whichever you use as it stands, and never the single "80 percent cleaning" figure that circulates as if one survey had measured it, because none did.

The reason behind both figures matters more than either number. Preparation time is mostly the cost of typed and absent data found late: reconciling three versions of a stock sheet, discovering in week three that the history you planned to train on was overwritten. For a scientist the worst case is sharper than for an analyst. An analyst with a missing history can report from today onward. A model with no labels cannot be trained at all. Every minute spent at door 4 asking "what was written down, and since when" is a minute not spent finding out after the kickoff.

DAMA-DMBOK, 2nd edition, chapter 15, names five levels of data management maturity: Initial/Ad hoc, Repeatable, Defined, Managed, Optimized. Five, not six: DMBOK has no level 0, and a "not started" level you may have met belongs to a different framework. The names are all that is borrowed. The question beside each rung is ours, written so a person who runs pharmacies can answer it about her own Friday.

Asked of Harbourline, the answers put the company between rung 1 and rung 2, and unevenly. The till does the same thing every day, because it has no choice, so sales sit at rung 2 at least. The stock sheet fails the rung-2 question: three versions are in circulation, so the same thing is not being done the same way. Nothing about the stock count is written down as a method, nobody checks it afterwards, and it is erased each Friday. The product master fails even the rung-1 question, because when a code is wrong nobody owns fixing it. The full assessment, with the practices behind each level, is a governance discipline; it is taught in the Governance 101 course ↗. In a discovery meeting the ladder is an interview aid and nothing more.

A model uses history in two roles, and the rung matters differently for each. A feature is something the model looks at: last month's sales, the day of the week, the supplier's lead time. A noisy feature makes a weaker model. A label is the answer the model is trained to reproduce: on this day, at this outlet, this product ran out. A noisy label makes a model that is confidently wrong in the same way the label was, and nothing downstream can tell.

So a rung-1 source can be a feature, with care, and it can never be the training label. If the stock count is typed three ways, the model learns the three ways. The bank's question g07 carries exactly that as its teach-back: "Where do the stock numbers come from, step by step?", then "A number typed by a person on a Friday behaves differently from one a till records. A model learns the typing habits too." Said out loud, it tells her why you care about a spreadsheet habit she had assumed was her problem, not yours.

Write the rung beside each source and never tell her the number. "Your stock data is a rung 1" is a grade, and a grade ends a conversation that was going well. What she hears is five questions that each made her notice something about her own shop; what you carry out is the one reading that matters for a scientist: which sources are steady enough to be a label, and whether any of them is the thing she wants predicted. At Harbourline none is.

For chronic medication, the best predictor of next week's demand is not last week's sales. It is when each regular patient is due back. Harbourline does not hold that. The bank's question g12 asks for it in her words: "What does the loyalty app know about your chronic patients, and who owns that data?" Teach-back: "Refill dates are the strongest signal there is for chronic demand, and owned means who can say yes to an export." Her answer is exact once the question is: the app vendor holds the refill dates, and an export needs a contract clause.

That is a label you cannot buy and a feature you cannot yet use, and both have a clock on them. The clause is a negotiation, not a login. Anything with Malaysian patient data also needs PDPA handling, and the head-office lawyer takes four weeks to answer anything. Write both into your notes as dates, not as data. A feature that arrives after the board meeting in six weeks is a feature for the second project, and saying so in the room is kinder than discovering it in week five.

Question g10 is short and has to be asked with a name in it: "Who can log in to the POS back office and pull an export?" Teach-back: "Access is the first blocker on most data projects, so I ask early and I ask by name." "IT can" is not an answer. "Kenneth can, and only Kenneth" is, and it is the answer that makes you ask what happens in January. For a scientist the stakes are specific: the three years of daily sales, the only history on the map with a past, sit behind one login.

The second half, that Kenneth is leaving and she has not told the team, does not come out on the first ask, whatever you ask. On the bench it sits behind the highest trust gate on her sheet, trust 3: she volunteers it only once several open questions with their reasons said aloud have shown her you are trying to help, not to audit. That is why door 4 is opened fourth. Ask it after the outcome, the Thursday decision and the pharmacist's WhatsApp, with the teach-backs in between, and you get the name, the date and the fact she has been carrying alone. Session 3 shows it as a number: the fact is worth 3 of the sheet's 68 points.

The POS product codes differ between Singapore and Malaysia, two outlets renamed products themselves last year, and nobody owns the product master. None of that is a feature, and none of it is a label. It is the join: the one table that says "these five codes are the same chronic-medication product". Without it, a model for 40 products across 38 outlets is really a pile of separate small models, each with less history than it looks like it has, and the Malaysian outlets, where supplier lead time is nine days instead of five, are the ones where a prediction has to see furthest ahead.

An unowned source is not a gap in your notes to fill in later. It is the first thing to propose an owner for. Priya in finance can give two hours a week; the product master is exactly the size of job two hours a week can hold. Session 5 turns that into one of three candidate projects, alongside the stock-out log and a simple rule a model would later have to beat.