The game is ridiculous. The problem isn’t.
If you have just searched SharePoint for FINAL_v7_REALLY_FINAL.xlsx, trusted a presentation promising 35% savings and discovered that the person who apparently knew why the decision was made left eighteen months ago, the joke may have felt slightly familiar.
That is the point.
The Assumption Maze is exaggerated. The behaviour behind it often isn’t.
Organisations can spend months selecting technology. Requirements are gathered, vendors demonstrate products, consultants advise, procurement negotiates, stakeholders meet and eventually somebody approves the decision.
Then the contract is signed.
The project moves on.
The evidence does not necessarily move with it.
Prove TDI was built around precisely this problem: technology decisions are fragmented across temporary artefacts when they should remain connected as a persistent organisational record.
THE PROBLEM
Can you still prove why you chose it?
Ask an organisation what technology it uses and somebody can usually answer.
Ask why that particular technology was selected, which alternatives were rejected, which claims were independently supported and what assumptions influenced the decision, and the answer can become considerably more complicated.
Some of it may be in SharePoint.
Some in email.
Some in the RFP.
Some in a spreadsheet.
Some in meeting minutes.
And some exists only in the memory of people who may no longer work there.
The organisation retains the technology.
It does not necessarily retain the decision.
THE RECORD
A decision is more than its final answer
“Vendor A was selected” is an outcome of a decision process.
It is not the decision record itself.
A defensible technology decision should retain the context around that conclusion:
- What did we actually need?
- What alternatives did we consider?
- What evidence supported each option?
- Where did that evidence come from?
- How current was it?
- What contradicted it?
- What risks did we knowingly accept?
- Who approved those trade-offs?
- Why did we ultimately choose one option over another?
And eventually:
Did it work?
Prove TDI keeps that context in a persistent Decision Ledger — a governed record of the decision itself — rather than treating a recommendation or a report as the system.
THE EVIDENCE
A claim is not evidence just because it made it into a spreadsheet
“Market leader.”
“Everyone else uses it.”
“Great demo.”
“Apparently 35% savings.”
“According to AI…”
These statements are not automatically false. That is precisely the problem.
A vendor might have good reason to believe its technology delivers 35% savings. A reference customer might genuinely achieve those savings. An analyst might regard the company as a market leader. An AI system might provide a perfectly correct answer.
But the moment a claim becomes part of an organisational technology decision, another question becomes necessary:
What actually supports it?
“Vendor claims 35% savings”
THAT IS INFORMATION
“35% saving expected”
THAT IS AN ASSUMPTION
“Independent evidence demonstrates comparable organisations achieved between X and Y under these conditions”
THAT IS EVIDENCE OF A DIFFERENT QUALITY
“We achieved 27% after twelve months”
THAT IS AN OUTCOME
THE SHELF LIFE
Evidence has a shelf life
Technology changes. Integrations change. Prices, security certifications, roadmaps and vendors change. So do your own requirements. Evidence that was sound on the day of the decision does not stay sound by itself — it has to be tracked.
Otherwise yesterday’s fact can become tomorrow’s assumption.
THE OUTCOME
What actually happened?
One of the most valuable pieces of evidence usually appears after the purchase: the outcome.
The decision promised things like:
- 20% lower operating costs
- improved workplace utilisation
- faster maintenance response
- reduced energy consumption
- improved employee experience
Did costs actually fall?
Did utilisation improve?
Did maintenance become faster?
Was energy reduced?
Did employees notice?
Without retained expectations, comparing expectation with reality becomes difficult. And an organisation that cannot compare the two cannot make its next decision any better than its last.
THE OUTPUT
The report should not become the memory
PowerPoints, board papers, recommendations, procurement documents and PDFs are outputs. They are not the persistent source.
Prove TDI produces a Proof Report as an approval-ready output: the recommendation, the alternatives, the supporting evidence, the unresolved risks and the rationale. But the report is an output of the governed decision record — not a replacement for it. The underlying Decision Ledger remains the persistent source.
THE LEDGER
What a retained decision actually looks like
- THE DECISION SCOPE
- What exactly was being decided?
- REQUIREMENTS
- What did the organisation actually need?
- ALTERNATIVES
- Which realistic options were considered or excluded?
- EVIDENCE
- What supported each material claim?
- CONTRADICTIONS
- What information did not agree?
- ASSUMPTIONS
- What had to be believed because evidence was incomplete?
- RISKS
- What could materially change the result?
- RATIONALE
- Why was one route preferred?
- APPROVAL
- Who accepted the trade-offs?
- VERSION
- What was known at that point in time?
- OUTCOME
- What actually happened afterwards?
THE TEST
Could your current decision survive the maze?
The game is fictional. The questions are not. Take a real technology decision and ask:
- Can we show the requirement?
- Can we trace the important claims to their sources?
- Can we show what alternatives were considered?
- Can we identify contradictions and unresolved assumptions?
- Can we explain who approved the trade-offs and why?
- Do we know what outcome we expected?
- Will we be able to compare that with what actually happened?
If several of those answers require searching old inboxes, the problem is probably not the maze.