Suppose you had to build a working AI project from a blank page. You could not train a model before deciding what problem it solves. You could not judge a model before it exists. Some order is forced on you — and it turns out to be the same order, every time.
An AI project moves through six stages: problem scoping, data acquisition, data exploration, modelling, evaluation, deployment. The cycle, not any single stage, is the unit of work. A weak stage caps every stage built on top of it.
The cycle is not a straight line. A poor result at evaluation sends you back to modelling, sometimes further, to data acquisition. Deployment itself feeds new data and new problems back to scoping — the loop, not the finish line, is what closes the project.
Before an AI project touches a single row of data, one stage comes first. Ask what you would need to know before building anything at all. You would need to know whose problem it is, what exactly is wrong, where it happens, and why it is worth solving.
Those four questions are the 4Ws — WHO, WHAT, WHERE, WHY. Answer all four before a single row of data is gathered. Skip one, and you find out only after collecting the wrong data.
A vague problem cannot be solved by a precise machine. The sharpness of the scope sets the ceiling for the whole project. No later stage, however careful, can recover what this first one left undefined.
Stage 2 begins once the problem is scoped. Now you gather data that actually fits it. Ask what data this problem needs. Find sources that hold it. Check each source is reliable. Collect only what is relevant.
More data is not the goal here. The right data beats more data chosen at random. A team can gather whatever is easiest to find, instead of what the scoped problem requires. That shortcut costs it at every stage that follows.
Remember the old rule: garbage in, garbage out. A model can only be as good as the data it learns from — no later stage can repair data that was wrong from the start.
Data Acquisition is not finished the moment data arrives. Ask why a whole stage exists just for getting data. The answer is simple: wrong data wastes every stage built on top of it, no matter how carefully those later stages are done.
The stage is done only when three conditions hold together. The right features are collected — the ones the goal actually requires, foreseen back at scoping. The source is reliable. And the quantity is sufficient for the analysis you planned.
Fail any one and the stage is not finished. The team returns to Problem Scoping, or repeats the collection — better to find that out now than after modelling has already begun.
Before collecting anything, the team must know what kind of data the goal needs. The kind decides which sources, which tools, and which charts apply later — get this wrong, and the whole plan built on it is wrong too.
Data splits two ways, asked at the same time. By measurement: numerical data is a number on a scale — the test is simply, can you average it? — while categorical data is a name or label you cannot meaningfully average. Numerical data splits once more: continuous can take any value in a range (temperature, height), discrete is whole counts only (students, goals scored).
By structure: structured data sits in rows and columns, each cell with a defined meaning; unstructured data — images, audio, free text — has no fixed format. Text and images are data too — the form differs, not the status. Most real projects need both kinds, on both axes.
"AI only works with numbers — text and images are not data."
Every piece of information an AI system uses is data. What differs is the form, and how it must be processed. Text is unstructured categorical data. An image is unstructured pixel data. The distinction changes which tools you use to collect it and whether you can chart it directly — it does not remove text or images from the category of data.
Not every source can be trusted, so before collecting a single row, the team judges the source itself. Four checks decide whether a source is fit to build on.
Recency: is it current enough for the question? Completeness: are rows or columns missing? Method: was it gathered systematically, or casually? Bias: does the collection favour some groups over others? Fail any one, and the data will mislead the model, however much of it you collect.
Quantity and quality are independent. A large dataset drawn from an unreliable source is simply a large unreliable dataset — more rows reinforce a bias, they do not dilute it.
"More data is always better — the bigger the dataset the more reliable it is."
A large dataset from an unreliable source stays unreliable. A biased collection method does not improve with more rows; it reinforces the bias at scale. Quantity and quality sit on separate axes. Run the four reliability checks first, then decide how much to collect.
Nila is planning a school-canteen food-waste project. She lists every feature she can think of — menu-item type, portion-size, day-of-week, student-count, amount-returned — and draws an arrow wherever one feature seems to influence another. It looks complete. It is not finished yet.
A system map like Nila's makes the whole data plan visible before a single row is collected: every feature is a node, every arrow an influence. Drawn after the features are named but before collection begins, it lets the team see what to gather, how effects flow, and which features overlap.
It would be easy to assume every node on the map gets collected. The map's real power is showing what cannot be collected — a feature that is unobservable, unethical, or simply unavailable. Nila's sixth idea, student dietary-restriction, cannot be collected without consent, so she draws it dashed: relevant, but cut from the plan.
Her six-node map — five active features, one dashed — yields a five-row acquisition plan. The map's job was to show what to cut before collection began, not after a failed attempt at it.
Weaker. The map alone. Five nodes — menu-item type, portion-size, day-of-week, student-count, amount-returned — plus a sixth idea, student dietary-restriction, that looks like a feature to collect just like any other.
Stronger. The map read honestly. Dietary-restriction cannot be collected without consent, so it is drawn dashed: it stays on the map as a relevant feature, but is cut from the plan. The six-node map yields a five-row acquisition plan, one source and one reliability note for each collectible feature.
"If a feature appears on the system map, it must be collected."
The map deliberately shows every feature relevant to the problem — including ones that cannot be collected, because they are unobservable, unethical, or unavailable. That is exactly the point of drawing it: the gap becomes visible while the scope can still be revised, instead of surfacing later as a failed collection. A feature you cannot collect is a scope signal, drawn dashed, not a task still owed.
ai-project-cycle-scope.system-map
/50-system/standards/book-look/cell1-a4/adv-kanada.png
Kanada
sparrow
Kanada's way was to break a whole into its real, separate parts. Do the same with your map: name each feature on its own, then keep only the ones you can actually collect.
Stage 3 comes before modelling, never after. Look at the collected data first: chart it, summarise it, and go hunting — for its patterns, its gaps, its surprises.
A problem you see now is cheap; the same problem found after modelling is expensive. Exploration turns a raw table into understanding. It catches the errors and holes that would otherwise be baked straight into the model, unnoticed until it fails.
Data Exploration does not end in a polished report. It ends in a decision: this data is ready to model, or this data needs revision or more collection first.
Its actual job is to study what was collected — chart it, find patterns, and hunt for problems: missing values, outliers, errors that slipped through acquisition unnoticed.
The honest verdict is rarely a clean all-ready or all-not-ready. It is usually partial and specific — ready on these features, not yet on that one — and specific is more useful than a comforting yes.
The Class 7 core was three charts — line, bar, scatter — and they still carry most of the work. The exploration toolkit adds five more, each filling a job the core three cannot.
A histogram shows the shape of one numerical variable's distribution. A pie or donut shows proportions of a categorical whole. A bubble chart is a scatter with a third variable added as size. A heat map colour-codes values across two categorical dimensions. An area chart shows a cumulative total over time.
Knowing each chart's purpose is what separates choosing from guessing. Eight charts, one job each — pick the one that answers your actual question.
With eight charts available, the choice depends on three things together: the data type, the number of variables, and the question the audience is actually asking.
The Class 7 rule still holds — groups to a bar chart, change over time to a line chart, relationship to a scatter plot, though the figure beside this text draws only three cells — histogram, line/area, and bar/pie-donut — so scatter is not among them. A chart can fit the data type and still mislead if it ignores the question.
Distribution of one numerical variable calls for a histogram. Proportions of a whole call for a pie. Two categorical dimensions call for a heat map — the fourth chart the figure leaves out. The question decides, not the data type alone.
"A pie chart can show any kind of data — it is the easiest to read."
A pie chart only works for categorical proportions of a whole, where the slices sum to 100%. Use it for a numerical variable like temperature over time, and the slices carry no valid meaning. Use it for more than six or seven categories, and it becomes unreadable. Easy to read describes a well-chosen chart — it is never, by itself, a reason to pick one.
Dhruv opens the food-waste data his team collected and makes two charts. He glances at both and says, "the charts look fine." That sentence is not a finding — it is a chart with no reading applied to it yet.
Reading a chart takes three moves, on any chart at all. First, the overall shape — rising, falling, flat, bell-shaped, or skewed? Second, the extremes — the highest and lowest points, and whether each is a real signal or a data error.
Third, the gaps — missing time periods, empty categories, thin regions with almost no points. Together, these three moves answer the real question exploration exists to ask: is this data ready to model?
The chart looked fine is not a finding. Real data always surprises — events cause spikes, missed collection leaves gaps, outliers may be genuine or errors.
Weaker. The glance. Dhruv makes a bar chart of average amount-returned per item and a line chart of weekly returns, looks them over, and calls it done: "the charts look fine."
Stronger. The three moves. Shape: most items sit in a narrow, ordinary range. Extreme: biryani stands out at a real 40% return — checked, and confirmed genuine, not an error. Gap: the item added in week 10 shows zero entries, not a zero return — a data gap, not a data point. His verdict: ready to model on the original items; the new one needs two more weeks of collection first.
"If the data was collected properly, the chart will be clean — there is nothing to find in exploration."
Real data always carries anomalies. Events cause spikes. Missed collection leaves gaps. Outliers may be genuine or may be errors — you cannot tell without checking. Exploration is not a check that the data is clean; it is the process of finding out what the data actually contains. "The chart looked fine" names nothing; "week-10 is a gap, not a zero" does.