Requirements work has a reputation problem. It is rarely the part of an AI project that receives the keynote slide, the demo video, or the executive applause. Nobody opens a budget meeting by saying, “What we really need is a better way to ask the system what it must know.” They should, but apparently civilization still has limits. ...
Questions look cheap. That is why they are dangerous. In most enterprise AI projects, the visible work arrives late: dashboards, RAG demos, knowledge graphs, compliance assistants, workflow copilots, and executive slides with arrows pointing to a “semantic layer.” The invisible work arrives earlier and is less glamorous: deciding what the system must actually know, answer, retrieve, distinguish, reject, and explain. ...
A requirement can survive three meetings, two approvals, and a legal review while still meaning different things to everyone who reads it. That is not usually because anyone is careless. Natural language is simply very good at sounding settled before its meaning is settled. Words such as “after,” “until,” “immediately,” and “within” feel precise in conversation. In software requirements, they can quietly conceal incompatible assumptions about timing, cancellation, and acceptable system behavior. ...
Inspection is not glamorous. It is not the robot demo, not the dashboard, not the moment a prototype obediently follows a traffic cone across a test track. Inspection is the slow, expensive discipline of asking whether the thing that worked once will behave acceptably when the weather changes, the path bends, the sensor gets confused, or the requirement was written by a tired engineer using the phrase “successfully complete” as if English were a formal language. ...