The requirement no one wrote down

Ask someone to write down how they do their job and the answer comes back clean: numbered steps, tidy handoffs, a flowchart if you are unlucky. Sit next to them for a morning and you watch the real process bend around exceptions the document never mentions. Nobody is lying. The part that matters most was never available to be written down, so a brief carries only what the organisation already knows how to say about itself, and the leverage hides in everything left out.

This is the gap that sinks AI projects. A team scopes a system against a requirements document, builds exactly what was asked, ships it, and watches it go unused. Every acceptance criterion passed. The work people do all day was somewhere else, buried in a habit or a workaround nobody thought to mention, because to the person running it a workaround does not register as a step.

We know more than we can tell

Michael Polanyi put it plainly sixty years ago: we can know more than we can tell.¹ Much of what a skilled person knows is unspecifiable and resists being put into words at all.¹ Nonaka later split knowledge along this seam. Explicit knowledge is codified and transmittable in formal, systematic language; tacit knowledge is personal, rooted in action and context, and hard to formalise or communicate.² Expert judgement is made of the second kind, which is the kind a requirements document cannot hold.

A better template does not repair that asymmetry. The expert is not withholding anything. The knowledge accumulated over years of doing the job without ever taking the form of words, which leaves an interview nothing to retrieve.

Why asking structurally fails

The requirements-engineering literature has known this for a long time and stated it bluntly. Domain experts hold large amounts of tacit knowledge that is not amenable to introspection; their answers to an analyst’s questions may therefore not match their actual behaviour.³ Stakeholders’ goals can conflict, and may not be explicit or may be difficult to articulate, which is why simply asking is not enough to gather requirements.⁴

There is a deeper point hiding in the vocabulary. The literature’s own verb is elicited (discovered, emergent, developed) rather than captured or collected.⁵ The process is communication-rich and error-prone, and a concept perfectly clear to one community can be entirely opaque to another, a gap that routinely goes unnoticed unless someone is paying specific attention to it.⁵ An interview optimises for whatever both sides already share words for, and the requirement worth the most sits outside that shared vocabulary.

The need is sticky

Eric von Hippel gave the economic version of this. When the information needed to solve a problem is costly to acquire, transfer, and use somewhere else (when it is sticky), problem solving tends to happen where that information already sits, rather than being relocated to a central analyst.⁶ The knowledge of how the work runs day to day is stuck to the person doing it, and every metre you drag it towards a workshop and a whiteboard costs fidelity.

Most discovery is organised against this grain: book a meeting room, bring the process owner in, ask the questions, write up the minutes, and hope the information survived the trip. Stickiness is the reason it usually has not. We send the engineer to the ward, the depot, or the claims queue instead.

Presence beats the questionnaire

Contextual inquiry means watching people do their actual work, in their own setting, while they do it, so nobody has to reconstruct their practice from memory. Done well, it surfaces the tacit, habitual, and workaround knowledge that users themselves may not consciously recognise.⁷ The prompt that earns the visit is “show me the last time this went wrong”, because the answer comes back with the workarounds still attached.

Resilience engineering names the gap this closes. Work-as-imagined is what designers, managers, and regulators assume happens, the version that makes it into the brief. Work-as-done is what people actually do to cope with real, variable conditions. The assumption that things go right because people work as imagined is the assumption that fails in practice.⁸ The distance between those two descriptions is what the visit is there to measure.

How we run it

1. 01

   Immerse before scoping. We embed in the work as actually done before we agree what to build, and we treat the brief as a hypothesis the observed work is allowed to amend.

2. 02

   Start from the last concrete instance. We watch the task in its own setting and ask what happened the most recent time it ran. Ask about the policy in general and the official version comes back. The workarounds only show up in the specifics.

3. 03

   Treat the gap as the spec. Where work-as-imagined and work-as-done diverge, that divergence is the highest-leverage thing in the room. We design for the second one.

4. 04

   Move the system to the knowledge. The need is sticky, so we take the engineering to where the work happens instead of dragging the problem to us. Onshore delivery, governance from the first commit, and row-isolated data all follow from that choice.

The method is not new. It has decades on the current AI cycle. The unglamorous truth of discovery is that the document was never going to be enough, and no amount of stakeholder workshops will turn tacit knowledge into a tidy list. The requirement that decides whether the system gets used is the one no one wrote down, because no one could. Go where the work is done, and stay until you can see it.