Availability
Does the data exist in a system, or in somebody's inbox and memory.
Design Pattern · September 2026
Data readiness before automation
Most assembled systems fail before any model runs, because the data they depend on is incomplete, inconsistent, or somewhere nobody checked.
Under the pillar Zero Neo
Four checks
Before a workflow is a candidate for automation, four questions have answers, in writing.
Quality
Is it complete and consistent enough that a rule applied to it produces the right answer most of the time.
Gaps
Which fields the workflow needs that nothing currently captures.
Alignment
Whether the data as recorded matches how the work is actually performed, or an older version of it.
The abandonment pattern
The failure has a shape and it repeats. Launch, visible excitement, early wins on the clean cases. Then inconsistent outputs on the messy ones. Staff begin double-checking, then stop trusting, then stop using. Usage drops, nobody escalates it, and the system is quietly deprioritised at the next planning round.
Almost none of that is a model problem. It is a data problem that was visible before the build and was not treated as blocking.
The Zero Neo implication
This is the most common way an assembled environment fails, and it argues for a specific sequence: consolidate and repair the data substrate before automating on top of it.
It also cuts against the hypothesis in one respect worth stating. A purchased application often arrives with an opinion about the data model, and that opinion, however ill-fitting, is a form of readiness the assembled version has to supply for itself.