The thread end to end, and its data

Open with the bank's question g01, teach-back first: "The workflow as it happens today is the spec. I cannot automate a step I have not watched a person do." Then: "Show me one thread from yesterday, start to finish. What did you do at each message?" Adeline calls Farid over and he scrolls. The supplier's confirmation arrives with items and prices in the supplier's own layout. He opens a second group, the one the outlet posts its orders in, and finds what the outlet asked for. He reads down both, item by item. He replies OK.

Stop him at the second group. That is the fact that reshapes the project, and it would never have come out of a request for "the chat history". The follow-up is g03, with its teach-back: "An assistant checks one message against another. If the other one lives somewhere else in another language, that is the real project." Then "Where is the outlet's original order, and what does it look like?" The answer: typed by the outlet manager, in a mix of English, Malay and Chinese, using product nicknames. There is no order table anywhere.

Write down what he did at each message, not what the message said. "Read the confirmation, opened the outlet group, matched by eye, replied" is a spec. "Supplier sent a confirmation" is a log line. The difference is the part a person does between messages, and that part is exactly what an assistant would be asked to take over.

Two numbers turn one watched thread into a workload. The first is volume: about forty threads a day per manager, and about four in five end in a plain OK. The bank's question g19 asks for exactly that, with its teach-back: "The share of plain OKs is the share an assistant can safely draft. The rest is where the person stays." It gives you the size of the routine part and, just as usefully, the size of the part that is not routine.

The second is variety: fourteen suppliers in Singapore and twenty-two in Malaysia, each writing its confirmation differently. Thirty-six formats is not a detail for later. It means there is no single message shape to parse, which is the first thing a developer assumes and the first thing the thread disproves. Ask to see a second thread from a different supplier before you leave; the difference between the two is the variety, in one glance.

Neither number needs trust to come out; they are facts she knows and states freely. The error rate, about one confirmation in twenty with a wrong price or a substitute, needs a little, and the question that gets it is in session 1. Watching the thread first is part of how that trust is earned: you have shown you care about how the work is done before you ask how often it goes wrong.

Two questions from the bank find the whole left side of that figure. The first is g11, teach-back first: "Where the messages live decides whether an assistant can even read them. That is a setup question, not a model question." Then: "Are the WhatsApp numbers personal phones or a business account? Can a chat be exported?" Adeline's answer is short and decisive. The numbers are the managers' personal phones. There is no business account and no API. A chat can be exported, one chat at a time, by hand.

Say what that means out loud, because it is the moment the project changes shape. An assistant cannot sit behind a personal WhatsApp number and read along. Anything it reads, somebody has to hand it, one chat at a time. That is not a problem a better model solves. It is a setup fact, and it belongs on the data-state map before any design is drawn.

The second is g04, with its teach-back: "If the record is a phone, the first thing an assistant should produce is a log, before it produces a single answer." Then "What happens to a thread once it is done? Where does the decision live?" This one needs a little trust, and it is why you ask it after the thread, not before. Nobody keeps a record of what was decided. The WhatsApp thread is the record. An area manager left in March and her phone went with her. For a pharmacy, where substitutions need a record by law, that is the most important box on the page, and it is empty.

Where a thing was born tells you what it is. How mature the habit around it is tells you how far you can lean on it. DAMA-DMBOK, 2nd edition, chapter 15, names five levels of data management maturity: Initial/Ad hoc, Repeatable, Defined, Managed, Optimized. Five, with no level 0. The names are borrowed, as reported from summaries; the plain questions are ours, and they are what Adeline hears. The ladder is taught in depth in session 2 of the data analyst sibling; for an AI developer it is five questions about the thread.

"When a confirmation is wrong, who catches it, and how do they know?" The manager, by eye, because she knows the outlet. "Does each manager do it the same way?" You do not know yet, and neither does the fact sheet; ask, and write down the answer she gives rather than the one you expect. "Is any of it written down?" No: the method is in three heads and the record is on three phones. "Does anyone check afterwards whether the OK was right?" Nothing she has said so far suggests anyone does. "Has it got better on its own?" Ask. On what she has told you, the matching habit reads as the bottom rung, with the second and fourth questions still open. That reading goes in your notes, never into the meeting as a grade.

The rung matters more for an assistant than for a report. A report built on an ad hoc habit is a report nobody trusts. An assistant built on one inherits the habit's variety as its training data and its test cases, with no written method to check its drafts against. The real maturity assessment is a governance discipline, taught in Governance 101; in a discovery meeting it is five questions and a note.

Two figures are usually run together into one, 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. In 2016 CrowdFlower's data science survey reported 60 percent of time spent cleaning and organising data and a further 19 percent collecting it. Different methods, different shapes of answer: a range for two activities together, and two separate figures. Quote whichever you use as it stands.

For an assistant at Harbourline, preparation has a concrete shape, and every piece of it is visible in the figure above. Somebody exports chats by hand from three personal phones. Somebody builds a dictionary from outlet nicknames to POS codes, twice, because the codes differ between the two countries. Somebody decides what to do about the decisions that were never recorded. None of that is model work, all of it comes before model work, and every piece was found by asking where a thing was born rather than asking for "the data".

Every lookup the assistant drafts is a match: this line on the confirmation is that line on the outlet's order. To match, it has to know that two different names are one product. The bank's question g09 asks for the thing that would let it: "Which system holds the product list, and do the suppliers use your codes?" Teach-back first: "An assistant can only match what it can look up. The product list is its dictionary."

Adeline's answer has two halves, and both land on the map. The POS holds the product list, so there is a dictionary. But the codes differ between the two countries, and the nicknames the outlets use are not in it. The dictionary is real and incomplete in exactly the place the matching happens. Filling that gap, nickname to product, outlet by outlet, is work a person has to do with the managers, and it is worth more to any assistant than a better prompt.

Question g10 has to be asked with a name in the answer: "Who can log in to the POS back office and pull the product list?" Teach-back: "Access is the first blocker on most projects, so I ask early and I ask by name." "IT can" is not an answer. "Kenneth can" is.

The rest of the answer does not come out on the first asking. Kenneth is the only IT person, he holds the POS admin login, he is leaving in January, and she has not told the team. On the bench that fact sits behind the highest trust gate on her sheet: she volunteers it only after several open questions with their reasons said aloud have shown her you are trying to help. It is worth 3 points, and it is the difference between an assistant with a dictionary and an assistant whose dictionary nobody can update after January. That is also why this question comes after the thread and not before it: asked cold, it gets "our IT guy".

Question g12 is short and easy to skip, and skipping it is how a supplier tool becomes a legal problem: "Do customer names ever appear in these threads?" Teach-back: "A name in a message turns a supplier tool into a personal-data tool, and that changes who has to approve it."

They do, sometimes, when an outlet orders a special item for a named customer. She mentions it once she trusts you a little. A patient name in a message makes it personal data under Malaysia's Personal Data Protection Act, and the head office lawyer takes four weeks to answer anything. So the box goes on the map in plum, labelled "must never see", and the approver changes from Adeline alone to Adeline and the lawyer. What the law requires in detail is not something to improvise in a discovery meeting; what you need is the fact that names appear, and the name of the person who will have to say yes.

The map above is the first thing you send Adeline after the meeting, before any prototype, before any proposal. Six boxes, a name or "nobody" wherever someone has to say yes, one key, one plum box. No word on it she would have to ask about. She can look at it on her phone and say "two of the outlets post their orders in a different group", or "Kenneth has a deputy who can log in too", and either correction is worth more than a week of building.

It is also your own honesty check before you design anything. A box that says "not recorded" means the project has a logging task before it has an assistant. A key on one person who is leaving means a continuity task before a dictionary. A plum box means an approval task before a pilot. An assistant proposed on top of a map with all three unaddressed is a demo, and session 5 is where those three tasks become candidate projects in their own right.