Most teams do not get the AI, ML, and deep learning distinction wrong because they lack knowledge. They get it wrong because they skip the deliberate check under deadline pressure and default to whatever sounds most impressive. A checklist fixes that. It turns a judgment call into a repeatable gate that anyone on the team can run.
Use the items below as a literal working tool. Run a candidate project through them before writing an estimate, choosing an architecture, or signing a vendor contract. Each item includes a short justification so you know why it earns its place.
Phase 1: Classify the Problem
Before any technical decision, establish which layer of the stack you are actually in.
Definitional checks
- Is the logic fully knowable in advance? If yes, you likely need rules-based AI, not ML. Justification: learning from data is wasted effort when the rules are already documented and stable.
- Does the problem require recognizing patterns from examples? If yes, you are in ML territory. Justification: this is the defining trait that separates ML from hand-coded automation.
- Is the input data unstructured (images, audio, video, raw text)? If yes, deep learning becomes a serious candidate. Justification: neural networks learn features from raw unstructured data that classical methods cannot easily engineer.
The framework article expands this classification into named stages if you want a deeper model.
Phase 2: Inventory the Data
Data realities override ambition, so confront them before committing.
Data checks
- Count your labeled examples. Hundreds to low thousands favors classical ML; tens of thousands or more is needed before deep learning is viable. Justification: deep learning starves and overfits on small data.
- Confirm data shape: structured or unstructured? Justification: tabular data usually belongs to gradient-boosted trees; raw pixels and audio belong to deep nets.
- Check class balance. If one class is rare, plan for precision and recall, not accuracy. Justification: accuracy lies on imbalanced problems.
- Estimate labeling cost. If you cannot fund the labeling deep learning demands, that is your signal to stay in classical ML. Justification: data work usually outweighs model work in effort and budget.
Phase 3: Define Constraints
Non-functional requirements quietly eliminate techniques, so name them early.
Constraint checks
- Do you need to explain individual decisions? If yes, weight toward interpretable models. Justification: black-box deep nets are unusable in regulated or client-facing decisions you must defend.
- What latency does the use case allow? Justification: large deep models can be too slow or costly for high-volume, real-time paths.
- What compute and budget are available? Justification: deep learning's GPU and training costs can dwarf the rest of a project.
- Who will maintain this? Justification: a team without ML expertise will struggle to keep a deep learning system healthy in production.
The trade-offs guide details how these constraints pull against accuracy.
Phase 4: Validate the Approach
Before full commitment, prove the choice cheaply.
Validation checks
- Have you built a baseline first? A rules or simple-ML baseline sets a floor and tells you whether complexity is even warranted. Justification: a one-week baseline is cheap insurance against a multi-month mistake.
- Does the simple version already hit the target? If yes, stop; do not escalate. Justification: marginal accuracy from a complex model rarely justifies its cost when simple already works.
- Is your success metric tied to a business outcome? Justification: a model that improves a vanity number but not revenue is a failure dressed as a win. See the metrics guide for choosing the right one.
Phase 5: Communicate Honestly
The last checks protect trust and prevent scope creep.
Communication checks
- Are you using precise vocabulary internally? Call rules "automation," learning systems "ML," neural nets "deep learning." Justification: loose internal language becomes false external claims.
- Do client-facing materials describe the actual technique? Justification: misrepresenting your stack collapses the moment a technical advisor asks a pointed question.
- Is the technique choice documented so nobody silently upgrades it? Justification: undocumented decisions drift, and a rules problem quietly becomes a model-training project.
How to Use This Checklist
Run phases 1 through 3 during intake, before any estimate leaves the building. Run phase 4 during the first sprint, as a gate before committing to a full build. Run phase 5 continuously, every time the project is described to anyone outside the team. The whole pass takes under an hour and routinely saves weeks.
A Worked Pass Through the Checklist
To make the tool concrete, run a quick example: a client wants to "use AI" to route incoming support emails to the right team.
Phase 1, classify
Is the logic fully knowable? Partly, some routing is keyword-driven, but phrasing varies enough that pure rules will miss cases. Does it require recognizing patterns from examples? Yes. Is the input unstructured? It is free text, which raises deep learning as a candidate. Initial read: classical ML, possibly deep learning.
Phase 2, inventory
You have 12,000 historical emails already labeled with the team that handled them. That is comfortable for classical ML and marginal for deep learning. The data is unstructured text, but the volume is modest. Class balance is uneven, with one team receiving most emails.
Phase 3, constraints
Decisions do not need deep individual explanation, but misroutes are annoying rather than catastrophic. Latency must be near-instant. The team has Python skills but no deep learning experience.
Phase 4, validate
A classical text classifier (TF-IDF features plus logistic regression or gradient boosting) is the baseline. If it routes the bulk of emails correctly, you stop there; the maintenance burden and data appetite of deep learning are not justified by the modest data volume and the team's skill set.
The checklist resolved the question in minutes: this is a classical ML problem, and the constraints actively argue against escalating to deep learning despite the unstructured input.
Adapting the Checklist to Your Team
The items above are a strong default, but tune them to your context.
- Add a security or privacy check if you handle sensitive data, since some techniques and hosted tools have compliance implications.
- Add a cost-ceiling item if budget is tight, forcing an explicit spend estimate before escalation.
- For teams new to ML, weight the maintenance check heavily, because a model nobody can maintain will fail in production regardless of its launch accuracy.
The checklist is a living tool. Revise it as your team encounters new failure modes, and the gate gets sharper with each project.
Frequently Asked Questions
When should I run this checklist?
Run the classification, data, and constraint phases during intake, before you write an estimate. Run the validation phase in your first sprint as a go or no-go gate. The communication checks apply continuously, every time the project is described externally.
What is the single most important item?
Counting your labeled data. Data volume and shape constrain technique choice more decisively than any other factor, and confronting it early prevents the most expensive mistakes, like scoping a deep learning project you cannot feed.
Can a project pass into deep learning territory later?
Yes. A project that started as classical ML because data was scarce may justify deep learning once data grows by an order of magnitude. Re-run the data phase of this checklist whenever your dataset grows substantially.
Why include communication checks in a technical checklist?
Because imprecise language causes real damage: it inflates scope internally and creates false promises externally. Keeping vocabulary honest protects both your timeline and your client relationships.
Does this replace a full project plan?
No. It is a decision gate that determines which technique to use, not a substitute for planning the build, data pipeline, and deployment. Think of it as the filter that runs before the real planning starts.
Key Takeaways
- Classify the problem, inventory data, define constraints, validate cheaply, and communicate honestly, in that order.
- Counting labeled data is the most decisive item; volume and shape constrain technique more than anything else.
- Build a baseline before committing, and stop escalating the moment the simple version hits the target.
- Name interpretability, latency, compute, and maintenance constraints early, since they silently eliminate techniques.
- Keep vocabulary precise and decisions documented to prevent scope creep and protect client trust.