The Shape of Failure: Before You Blame the AI

Every automated system receives a particular shape of the world. That shape is expressed through records, documents, events, exceptions, and missing values. If the designers have not identified those forms—and the ways they can become malformed—the machine inherits their ignorance and reproduces it at scale. The question is not simply whether the AI failed. The useful question is whether the human-built system knew what success meant, knew the shape of its data, and knew how to recognize when it was wrong. Start with the shape of the data Before selecting a model, draw the workflow as a sequence of data transformations. What enters each stage? In what form and from what source? Which values are valid, absent, duplicated, stale, delayed, or contradictory? How will each violation be detected? What must the workflow do next? Each data shape needs a corresponding failure model. An unknown here is not merely uncertainty for the machine; it is a measurement failure in the organization. The remedy is to collect the missing data or explicitly design for its absence. Otherwise, the system is being asked to operate in a world its designers have not described. Stabilize the deliverable A system cannot be stabilized around a target that continues to move. The deliverable must be more than an aspiration written in a prompt. It should be expressed as observable conditions and anchored to a representative corpus: examples that are acceptable; examples that are unacceptable; examples that are genuinely ambiguous. Human reviewers should first demonstrate that they can apply those distinctions consistently. If they cannot agree on what success looks like, the model is not being measured against a specification. It is being measured against human disagreement disguised as one. The model is not the system Only then does it become meaningful to place an AI model inside the workflow. The model is one transformation among many: Input → validation → retrieval → normalization → model infere