Assumption Auditing

Visible risks get managed. They appear in risk registers, get assigned owners, and receive mitigation plans. Hidden assumptions, as explored in the PM safety guardrails gap, — the beliefs so deeply embedded in a team's shared context that nobody thinks to question them — receive none of this attention. A product roadmap might explicitly account for competitive threats and budget constraints while silently assuming that customers want the feature being built, that the target market segment behaves like last year's, or that a key integration partner will remain available on current terms.

The cost of a wrong assumption is typically higher than the cost of a materialised risk precisely because it is unmanaged. A risk that materialises triggers the contingency plan. An assumption that fails triggers a crisis, because there was never a contingency — no one imagined it could be wrong. Projects that fail rarely cite "a risk we identified but failed to mitigate" as the cause. They cite "something we never considered."

AI models are effective at surfacing these assumptions precisely because they lack the insider context that makes assumptions invisible to the team. When you describe a plan to an AI, it processes the text without the shared institutional knowledge that causes internal teams to treat certain premises as self-evident. This outsider perspective is the tool's primary value in assumption auditing. The technique pairs well with <a href="/aisapedia/claim-decomposition">claim decomposition</a>, where a single bold prediction is broken into its component parts — assumption auditing applies the same logic at the project level.

The core technique is straightforward: describe the initiative in full context — goals, timelines, resources, market conditions, dependencies — and ask the model to list the assumptions that must hold true for the plan to succeed. The prompt should request that assumptions be ranked along two dimensions: how likely each is to be wrong, and how much damage a wrong assumption would cause. This two-dimensional ranking surfaces the assumptions that matter most: the ones that are both fragile and load-bearing.

Effective audits require specificity in the input. Using domain prompt templates ensures this specificity is consistent across audit sessions. Vague descriptions yield generic assumptions like "you assume the market will grow," which are true but useless. Providing concrete details — revenue targets, customer segments, technical dependencies, hiring timelines, pricing models — gives the model enough surface area to identify non-obvious premises. A structured prompt like "List assumptions about our customers, our market, our technology, our team, and our timeline that this plan depends on" organises the output across multiple risk categories and prevents the model from clustering all assumptions in one domain.

Once you have the ranked list, the next step is empirical: pick the highest-risk assumption and design a test. This might be a customer interview, a prototype, a data pull from existing systems, or a competitive analysis. The goal is to convert the most dangerous assumption from belief to evidence before the project reaches a point of no return. Many teams find that the single act of designing a test reveals that the assumption was never examined — and that the test itself takes hours, not weeks, to run.

The main failure mode is treating the AI's assumption list as exhaustive. Applying diagnostic follow-ups after the initial audit helps surface assumptions the model missed. Models generate assumptions based on patterns in their training data, which means they are good at surfacing common categories of risk — market assumptions, technical assumptions, resource assumptions — but can miss domain-specific or highly contextual risks that fall outside typical patterns. An AI auditing a pharmaceutical launch plan might miss regulatory assumptions that a domain expert would flag immediately, because the model's coverage of pharma regulatory edge cases is thinner than its coverage of general business strategy.

Another pitfall is anchoring on the AI's risk ranking without applying domain expertise. A model might rank a technical assumption as high-risk because integration failures are common in its training data, while the team knows their specific integration is already tested and stable. The ranking is a starting point for expert discussion, not a verdict. Teams that delegate the prioritisation entirely to the model miss the opportunity to apply their contextual knowledge where it matters most.

Teams also sometimes confuse assumption auditing with <a href="/aisapedia/adversarial-testing">adversarial testing</a>. An assumption audit asks "what are we taking for granted?" while adversarial testing asks "how could this actively be broken or exploited?" Both are valuable, but they serve different purposes and require different follow-up actions. An assumption audit might surface "we assume users will complete onboarding" — a passive risk. Adversarial testing would ask "how could a malicious actor exploit the onboarding flow?" — an active threat. Conflating them dilutes the value of both.

In practice, teams often find that running an assumption audit at two specific moments delivers the most value: at the start of planning (when assumptions are being set and are cheapest to test) and at major decision gates (when the cost of a wrong assumption increases sharply because resources are about to be committed). Adding it to every weekly meeting creates fatigue and trivialises the exercise; reserving it for high-stakes moments keeps it effective and respected.

Some teams maintain a living assumptions register — a shared document where each identified assumption is logged alongside its current status (untested, being tested, validated, invalidated, accepted as risk). This register feeds naturally into broader decision frameworks for AI-informed planning. This register becomes an input to subsequent AI sessions, allowing the model to focus on new or changed assumptions rather than regenerating the same list. The register also serves as a decision trail: when a project encounters an unexpected obstacle, the team can check whether it was a known assumption that was accepted as risk or a genuinely unforeseen condition.

The most mature implementations combine assumption auditing with <a href="/aisapedia/stakes-based-review">stakes-based review</a> — applying more rigorous auditing as the stakes increase. An internal process change might warrant a quick AI audit. A major product launch or market entry deserves a thorough multi-session audit with domain experts reviewing the AI's output and contributing assumptions the model missed.