简体中文
EnglishWhat is the Machine Learning Canvas and what goes in its 10 boxes?
Updated
The Machine Learning Canvas is a one-page planning tool from OWNML that lays out everything a team has to agree on before anyone builds an ML system. It has 10 boxes covering the full chain from what is being predicted through to what happens after the system ships: Predictions, Data, Task, Decisions, Impact, Value Proposition, Collection Sources, Models, Features, and Monitoring. It is meant to be filled in together, in one place, before the first line of code, so that the people who own the answers are in the room when the definition gets fixed.
Why one page instead of a spec document
The canvas exists because ML projects fail on definition, not on modeling. OWNML's framing is blunt: "The project is yours to land. The definition isn't yours alone to fix." Three weeks in, a team can still disagree on what counts as churn, who acts on the score, or what a false alarm costs — and you cannot ship past a disagreement like that, nor settle it alone.
Two failure patterns the canvas targets:
- "AI-driven churn prediction" meant five different things to the five people who approved it. It shipped, and nobody agrees whether it worked.
- Twenty AI ideas on the list, enough people to build five, and no common way to compare them.
A single shared page gives every project the same terms of comparison, so funding decisions and scope decisions happen on the same basis.
The 10 boxes
| Box | What it captures |
|---|---|
| Predictions | What the system predicts |
| Data | The data involved |
| Task | The ML task being framed |
| Decisions | What decision the prediction feeds |
| Impact | What a mistake costs |
| Value Proposition | Why the system is worth building |
| Collection Sources | Where the data comes from |
| Models | The modeling approach |
| Features | The inputs the model uses |
| Monitoring | What happens after the system ships |
The ordering matters: it runs from what is being predicted through to post-launch monitoring, so the boxes that usually get deferred (impact, monitoring) are filled in at scoping time rather than reconstructed later.
What running the canvas gets you
A funding decision you can make before code exists. The Impact box forces the numbers that matter: what a false alarm costs, what a miss costs, and the accuracy a model would have to reach before it is worth building at all. That lets you compare projects on the same terms.
A spec engineers or agents can build from. Precise enough to work from directly, instead of reconstructing intent later from a deck and a chat thread. It also answers what an AI coding assistant would otherwise have to guess: what is knowable at decision time, and what counts as success.
Compliance documentation, built in. The canvas holds the intent, data, decision, and monitoring documentation that regulatory model reviews ask for — written during scoping instead of months later.
Fewer rounds to production. OWNML cites a consultancy building anomaly detection for a US telecom manufacturer that stopped modeling after several rounds because the problem was not defined well enough to build against; fixing the definition first is what got the system live.
How to use it in practice
- Get the people who own the answers in one room — the ones accountable for the decision, the data, and the outcome, not just the builders.
- Fill the boxes in order, starting from Predictions and Decisions, and do not skip Impact or Monitoring.
- Use the completed page to decide whether to fund the project, and to compare it against other candidates on identical terms.
- Hand the same page to whoever builds it as the working spec.
OWNML reports that 15,000+ people have downloaded the canvas since 2015, and offers a free 30-minute project review on a project you are scoping, plus a separate conversation for planning ML across several teams.