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.
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.
Stage 4 is where the decision-making system gets built. The first choice is not which algorithm — it is a simpler question. Is the rule that governs this decision already known and stable?
If yes, write the rule directly: rule-based. If the rule is hidden inside the data, and too complex to state in words, a learning-based model has to infer it from examples instead.
The choice follows the problem, not fashion. Neither path is the advanced one — each fits a different kind of problem, and picking the wrong one wastes the whole stage.
Class 8 named the two paths. Class 9 asks the sharper question: how do you actually choose? Not by instinct — by weighing four factors together.
How complex is the pattern — can an expert state it in words, or not? How much labelled data do you have? How costly is a wrong answer, and must the logic be checkable by an inspector? And must the decision be explainable to the person who acts on it?
Rule-based fits a simple, statable pattern that must be auditable. Learning-based fits a pattern too complex to write down, where enough labelled examples exist to learn it from. The diabetic retinopathy (DR) screening tool shows how the four combine, not just two: no expert can write, in words, the exact retinal signs of early damage (complexity). And enough labelled retinal images already exist to learn the pattern from (labelled data) — both point to learning-based.
Cost and explainability point the other way, toward rule-based — not toward learning-based. A missed case costs real vision, and the decision must be explainable to the person who acts on it: both factors argue for the simpler, auditable path, even though complexity and labelled data argued for learning-based just above.
So the team chooses learning-based anyway, and builds the missing safeguard in: every flagged scan still goes to an ophthalmologist before anyone acts on it, and that check supplies the explainability a bare model score cannot. Weighed honestly, the four factors are not unanimous — two pull each way, and the audit step is what makes the learning-based pick acceptable.
Weigh the four honestly and the choice stops being a guess. The common slip is assuming learning-based always wins because it is more powerful — it fails with too little labelled data, or a decision no one can explain.
Stage 5 is where you judge the model honestly, and honesty here is harder than it sounds. A single accuracy number can hide real failure.
A model can score well overall and still be wrong in exactly the cases that matter most. A single accuracy number can hide failure — "looks good" and "is good" are not the same claim.
Honest evaluation tests on data the model never saw during training. It also looks at which kind of error the model makes — not only how many errors, but which ones, and what each one costs.
It feels natural to sum a model up in one number: how often is it right? That single number hides more than it reveals.
A prediction has not one result but four. Two are correct — a true positive, rightly saying yes, and a true negative, rightly saying no. Two are wrong — a false positive, a false alarm, and a false negative, a genuine miss.
The two wrong outcomes are not equal. A missed disease and a false alarm cost entirely different things. That is exactly why one accuracy figure is not enough to judge a model — it treats both mistakes as the same mistake.
ai-project-cycle-build.four-outcomes
/50-system/standards/book-look/cell1-a4/adv-sushruta.png
Sushruta
tailorbird
Sort before you judge — one accuracy figure hides four different outcomes, and until each sits in its own clean bin you do not yet know what kind of mistake you are making.
An honest score needs one more safeguard. Testing on the same data measures memory, not skill — a model tested on the examples it learned from will always look better than it truly is.
The fix is a two-step recipe. Split the dataset before training begins. Train on the larger part. Keep a held-out part completely untouched, and use it only once, at testing time.
Only a score measured on data the model has never seen tells you how it performs on the world it will actually meet.
Take a mango sorter, trained on Alphonso mangoes photographed in afternoon light. Feed it Dasheri mangoes under a different bulb. Does it pause, and say, "wait — I do not recognise these"?
It does not. It keeps sorting, handing back a confident YES or NO on every single fruit — even though those answers can no longer be trusted.
A model has no inner voice. It cannot tell you when it has left the conditions it was trained and tested on. It just keeps answering, exactly as sure of itself as before, while its real accuracy quietly falls apart underneath the confidence.
That blind confidence, with nothing inside to raise a flag, is the AI blindspot. It is exactly why a deployed model must be watched from the outside — it will never warn you itself.
Stage 6 puts the model into real use, and watches it there. Shipping the model is not the end of the work — it is the start of a different kind of work.
Monitor whether it still performs as well in the real world as it did in testing. Watch for drift, as the conditions around it change in ways the training data never showed it.
Deployment is where the cycle closes and restarts — not where it ends. New data and new problems it surfaces feed straight back to Problem Scoping.
It is tempting to think the project ends once the model is deployed and working. It does not. Deployment opens three ongoing jobs, not one act of shipping.
Access: put the tool in a form real users can actually reach — a tablet app, a printout, an API — with no expert needed on site. Monitoring: check regularly whether the scoreboard is drifting from its launch numbers, against an agreed threshold that triggers a flag-and-retrain.
Limits communicated: the tool's evaluation limits must reach every user who acts on its output, printed on every result — never buried in a manual nobody reads.
The work starts at shipping and ends only at retirement. A model shipped and then forgotten drifts quietly into danger, with nobody watching.