The Vagueness Problem
You know specification matters. Here's why your team still can't do it.
Every team I’ve worked with in the last year agrees on one thing: specification matters.
They’ve read the articles. They’ve seen the failures. They nod when someone says “define what ‘good’ looks like before you build.” Then they go back to their desks and write requirements like “improve the customer onboarding experience.”
Knowing that specificity matters and being able to produce it are entirely different skills. The gap between them is where most AI initiatives are stuck right now – not because teams are ignorant, but because specification is a fundamentally different kind of cognitive work than most professionals have ever been asked to do. This is the why before what in its purest form: teams jump to “use AI to improve the proposal process” without specifying why they’re improving it – and the missing why is where every downstream interpretation diverges.
The Skill Nobody Trained You For
Business education optimizes for flexibility. MBA programs teach frameworks for ambiguity. Management training emphasizes adaptability, “strategic thinking,” navigating uncertainty. Career advancement rewards people who can hold multiple possibilities open simultaneously.
Specification demands the opposite. It demands locking down what you mean. Eliminating interpretive room. Committing to criteria that someone else can check without asking you what you intended.
These are opposing muscles. The same professional who excels at “keeping options open” during a strategy session will struggle to produce a requirement specific enough for a system to execute. Not because they lack intelligence. Because specificity requires a mode of thinking their entire career has trained them away from.
Consider the difference between these two statements:
“We need the AI to produce high-quality customer communications.”
“Every customer communication must include a specific next action, reference the customer’s most recent interaction, use no more than three sentences per paragraph, and never speculate about timelines the operations team hasn’t confirmed.”
The first sounds professional. The second sounds pedantic. In a human organization, the first is more useful – it gives people room to apply judgment. For AI, the second is the only one that means anything. The first produces confident-sounding output that will be wrong in ways nobody can pinpoint until a customer complains.
There’s an irony here. The discipline of being explicit – locking down what you mean, stating problems with enough context that they’re solvable without follow-up questions – transfers. Leaders who develop it for AI find they write clearer briefs, run tighter meetings, delegate with less rework. The specification muscle makes everything better. But building it requires unlearning habits that made you successful in a world where humans filled in the gaps charitably.
The uncomfortable truth: the skill that made you effective at managing humans makes you worse at specifying work for AI. And it’s the leaders who are most experienced – who’ve spent decades navigating ambiguity, who personally step in to fix things because “it’s faster” – who have the hardest time switching modes. They’ve been the human interpretation layer for so long that they don’t see the specification gap they’re personally bridging every day.
The Specificity Cascade
One vague requirement doesn’t stay vague in isolation. It contaminates everything downstream.
Here’s how it works. A VP says: “Use AI to improve our proposal process.” That sounds reasonable. It even sounds specific – there’s a named process. But watch what happens next.
The project lead interprets “improve” as “faster.” The sales team interprets it as “more customized.” The legal reviewer interprets it as “fewer compliance issues.” Nobody surfaces these differences because the original instruction was vague enough to accommodate all three interpretations. Everyone feels aligned.
Now the implementation team needs success criteria. They inherit the VP’s vague requirement and produce vague acceptance criteria: “proposals should be higher quality and delivered faster.” These criteria flow into task decomposition. Each task inherits the ambiguity. The prompt engineer writes prompts against vague tasks. The AI produces vague output. The human reviewer – who also doesn’t have clear criteria for “good” – reviews against instinct.
The proposal looks polished. The VP sees it. “That’s not what I meant.”
Nobody was wrong at any step. The vagueness compounded. Each layer amplified the interpretive gap until the final output bore almost no relationship to the original intent.
The cascade gets worse when the process itself was never documented. Many workflows exist only in the heads of the people who built them – held together by institutional memory, Excel spreadsheets, and copy-paste routines that nobody ever had to articulate. These processes worked because the same person who designed them was running them. The specification lived in their habits, not in a document. Ask them to write it down for an AI to execute and you discover the specification never existed. What existed was a person.
This is why specification can’t be solved at the prompt layer. By the time a requirement reaches a prompt, it’s been through three or four translation steps – often through processes that were never specified to begin with. If the source was vague, no prompt engineering can recover the lost specificity. You can’t be precise about an instruction that was never precise to begin with.
The Political Cost of Clarity
Specification isn’t just cognitively hard. It’s politically expensive.
Being specific means making trade-offs visible. “We’re optimizing proposals for speed, not customization depth” is a statement someone has to own. It means the sales team can point to a decision and say “this is why we lost the Meridian deal – because the proposal was fast but generic.”
Vagueness prevents that. When the requirement is “improve the proposal process,” nobody is accountable for the trade-offs embedded in “improve.” If the proposal is fast but generic, that wasn’t anyone’s decision. If it’s customized but slow, that wasn’t either. The vagueness distributes accountability so thinly that it disappears.
This is rational behavior. In most organizations, being wrong about a visible decision costs more than being vague about an invisible one. Specification creates artifacts – written criteria, checkable standards, explicit trade-offs – that can be evaluated, debated, and blamed. Vagueness creates nothing to evaluate.
There’s a subtler version of this: leaders who absorb specification costs personally without making them visible. A director who manually fixes AI outputs every morning because “it’s faster than writing a proper spec.” A team lead who reviews every proposal herself because the criteria exist only in her head. These leaders are doing the specification work – they’re just doing it in real time, invisibly, and never documenting it. The process appears to work. Nobody sees the bottleneck. And when that person goes on vacation, the whole thing breaks, because the specification walked out the door with them.
But here’s what’s changed: AI makes the cost of vagueness immediate and measurable. When a human received “improve the proposal process,” they asked clarifying questions, applied judgment, iterated over coffee. The specification gap was filled through human interaction that nobody tracked. When AI receives the same instruction, it guesses. The output is wrong. The failure is visible. And it happens in seconds, not weeks.
Organizations that could tolerate vagueness with human workflows can’t tolerate it with AI. The hidden subsidy of human interpretation has been withdrawn. But the way through the political cost isn’t to pretend it doesn’t exist – it’s to reframe what specification actually is. Specification isn’t bureaucracy. It’s risk reduction. Every vague requirement that reaches an AI system is an unpriced bet that the output will match someone’s unstated expectations. Making the specification explicit doesn’t add overhead – it makes visible the overhead that was always there, just hidden in rework cycles and escalation meetings. Teams that frame specification as de-risking implementation spend, rather than adding process, find the political resistance drops considerably.
False Specificity
There’s a failure mode worse than vagueness: looking specific while remaining vague.
“Reduce proposal turnaround time by 30%.” That sounds specific. It has a number. It has a metric. But what counts as “turnaround time”? From when the opportunity is identified? From when the client requests the proposal? From when the sales team submits the brief? Each definition produces a different baseline and a different target.
“Ensure all proposals comply with brand guidelines.” Specific-sounding. But which brand guidelines? The 47-page brand book nobody has read since 2023? The informal rules the marketing team enforces inconsistently? The guidelines the VP personally prefers, which contradict the brand book on three points?
False specificity is more dangerous than open vagueness because it shuts down the clarifying conversation. When a requirement is obviously vague, people ask questions. When it appears specific, they assume the work is done. The team builds against a phantom target, confident they’re on track.
This is what produces the 80% problem – AI output that’s almost right but not quite, where the rework takes longer than doing the task from scratch. The specification looked complete. It had numbers, metrics, named processes. But it didn’t survive contact with reality because the definitions underneath the numbers were never locked down. Stack Overflow’s 2025 developer survey found that 66% of developers report “AI solutions that are almost right, but not quite” as their most commonly cited frustration. The “almost” is false specificity at work.
The test is simple: could someone who wasn’t in the room check this requirement without asking you what you meant? If the answer is no, you have the appearance of specificity without the substance.
The Specificity Audit
Diagnosing vagueness is useful. Fixing it requires a process. Here’s the one I’ve been developing and pressure-testing with teams.
The Specificity Audit is a structured sequence for converting vague requirements into checkable specifications. It produces three artifacts and answers five questions. It works for any requirement, at any level – strategic intent, project scope, task definition, prompt instruction.
The Five Questions
Run these against any requirement before you build.
1. What does “done” look like – in terms a stranger could verify?
Not “done” as in “I’ll know it when I see it.” Done as in: someone who has never met you, who doesn’t share your context, who can’t ask you a follow-up question, could read the output and confirm it meets the requirement. If your definition of done requires the author’s interpretation to evaluate, it’s not a specification. It’s a preference.
2. What’s excluded?
Scope creep lives in what isn’t said. “Improve the proposal process” doesn’t say whether that means the initial draft, the review cycle, the approval workflow, or the delivery format. Specification requires boundaries. What is this requirement explicitly not about?
3. What trade-off does this requirement embed – and who decided?
Every specific requirement encodes a prioritization. “Three sentences per paragraph maximum” prioritizes scannability over depth. “Reference the customer’s most recent interaction” prioritizes personalization over speed. Name the trade-off. Name the person who owns it. If nobody owns the trade-off, the requirement isn’t ready.
4. What would a wrong-but-plausible output look like?
This is the question that catches false specificity. If you can describe what a plausible failure looks like, you understand your requirement well enough to enforce it. If every output would look “fine,” your criteria aren’t specific enough to distinguish success from failure.
5. What happens at the boundary?
Requirements break at the edges. “Reference the customer’s most recent interaction” – what if there is no recent interaction? What if the most recent interaction was a complaint? What if there were three interactions on the same day? Boundary cases expose the assumptions your requirement is built on. If you can’t answer boundary questions, you’ve specified the easy middle and left the hard edges undefined.
The Three Artifacts
A complete specification produces three things. Without all three, you have fragments that feel complete but aren’t.
The Contract – a plain-language statement of what the system will do, what it won’t do, and how to check whether it did it. This is the testable promise. It answers: what are we agreeing to deliver, and how will we know if we delivered it?
The Scenarios – three to five concrete examples of correct output and at least two examples of plausible-but-wrong output. Scenarios make the contract tangible. They prevent the contract from being interpreted differently by different people. The wrong-but-plausible examples are the most important. They define the boundary between success and failure.
The Invariants – the things that must always be true regardless of context. “Never speculate about delivery dates.” “Always include a source for any numerical claim.” “If the customer’s account shows an open support ticket, do not offer a promotional discount.” Invariants are the guardrails that survive edge cases. When everything else is ambiguous, the invariants hold. Notice how invariants often emerge directly from boundary questions: ask “what if the most recent interaction was a complaint?” and you discover the invariant “never offer a promotional discount to a customer with an open support ticket.” The Five Questions generate the Three Artifacts – that’s the audit’s structural logic.
The Sufficiency Test
How do you know when you’re specific enough? Apply this check:
Hand the specification to someone who wasn’t involved in creating it. Ask them to evaluate three AI outputs against it – without talking to you. If they can do it and their evaluations match yours, the specification is sufficient. If they need to ask you a question, the specification has a gap. The question they ask tells you exactly where the gap is.
This sounds demanding. It is. That’s why most specifications fail – not because teams don’t try, but because they stop at the point where the specification feels right to the person who wrote it. The person who wrote it carries context the specification doesn’t contain. The sufficiency test strips that context away.
Running the Audit
The Specificity Audit isn’t a one-time event. It’s a practice that improves with use.
Start with a requirement your team is currently working with. Run the five questions. You’ll discover that most requirements fail at question one – the definition of “done” requires interpretation. That’s normal. The first pass through the audit is diagnostic. It tells you where the vagueness lives.
The second pass produces the artifacts. Write the contract. Generate the scenarios – and pay particular attention to the wrong-but-plausible examples. Define the invariants. This pass takes longer than most teams expect, because writing good scenarios requires confronting trade-offs that the original requirement was designed to avoid.
The third pass is the sufficiency test. Hand the specification to someone outside the project. Watch where they get stuck. Every question they ask is a gap in the specification. Fill the gaps. Test again.
Teams that do this consistently report a pattern: the first audit takes hours. The fifth takes thirty minutes. Not because the requirements got simpler, but because the team developed the muscle. They start writing specifications that survive the sufficiency test on the first pass. They catch vagueness upstream, in the meeting where the requirement is first discussed, before it enters the pipeline.
The Specificity Audit doesn’t make specification easy. It makes it systematic. And systematic beats intuitive when the stakes are high enough to measure.
What Changes When You Get Specific
The immediate benefit is better AI output. That’s the obvious one.
The deeper benefit is organizational clarity. Teams that run the Specificity Audit regularly report that the process surfaces disagreements that were previously hidden in vague requirements. The VP and the sales lead discover they have different definitions of “improve.” The project manager and the legal reviewer discover they have incompatible success criteria. These disagreements existed before the audit. The audit made them visible before they became failures.
This is the paradox of specification: it feels like it slows you down, because it forces conversations that vagueness was designed to avoid. But those conversations were going to happen eventually – as a failed pilot, a scrapped prototype, a frustrated VP saying “that’s not what I meant.” The Specificity Audit moves the conversation from the failure post-mortem to the planning stage.
The industry is converging on a name for this: specification engineering – a shift articulated prominently by Sean Grove at OpenAI and echoed by practitioners including Nate B. Jones, who has written about the shift from prompting to specification persuasively. Anthropic’s engineering guidance reinforces the same lesson: agent quality improves when teams define tasks, interfaces, and evaluation clearly instead of relying on vague general instructions. The specification is becoming the prompt.
The Specificity Audit is the diagnostic layer underneath. Specification engineering asks “how do you write good specifications?” The audit asks the prior question: “how do you know if your specification is good enough?” That’s the gap most teams fall into. They agree specification matters. They even attempt it. They produce something that looks specific. And then they ship it without ever testing whether the specificity is real or performed. The audit is the quality gate for the specification itself.
If you’re a leader trying to justify the time investment, here’s the framing that works: the Specificity Audit isn’t process overhead. It’s the quality gate for your implementation spend. Every hour spent on specification saves multiples in rework, failed pilots, and the slow erosion of organizational trust in AI that comes from shipping vague instructions and getting vague results back. The cost of specificity is time and political discomfort up front. The cost of vagueness is wasted implementation and eroded trust downstream – and the trust, once eroded, is the hardest thing to rebuild.
The Vagueness Problem sits in the “Before You Build: Foundation” layer of the Enterprise AI Blueprint. It connects to the Specification Gap and C.E.P. Framework – but where those frameworks answer “what should you specify” and “how do you define correctness,” the Specificity Audit answers “how do you know if you’ve been specific enough.”
If your team keeps saying “improve X” without defining what improvement looks like – or worse, if they think they’ve defined it and haven’t – I’d like to hear how you’re navigating that. What does the gap between knowing specification matters and actually producing it look like in your organization?