Probabilistic
Thinking in a
Deterministic World

Some questions have determinate answers. What did we invoice this client last quarter? Which of these contracts contain an arbitration clause? What does clause 14 actually say? These are retrieval and computation problems. A fact exists, and the system either returns it or it doesn't. Here certainty is the goal, ambiguity is failure, and the engineering job is to squeeze the probability out of the pipeline.

Most of the work that decides whether a company thrives is not that kind of question. How should we position this? What is actually wrong with this process? Which of these three strategies fits who we are? What should this paragraph say? These have no determinate answer. They have better and worse answers, judged against criteria that are themselves partly subjective - and which are often only discovered in the act of doing the work.

The error is applying the certainty posture to the second category.

It is the most common mistake we see, and it is expensive in a way that is hard to notice, because its output looks like success.

Ask a model a subjective question and it hands back one polished answer. Something specific has just happened: a distribution of plausible responses was collapsed to a point near its centre. For a factual question that is exactly what you want. For an open one, the most probable answer is close to the average of everything ever written on the subject. It is, almost by construction, unremarkable.

Worse, it arrives with the same fluency as a verified fact. Confidence is not calibrated to the type of question being asked. A plausible-sounding answer to an open question causes premature convergence: the team stops generating, anchors on what it was given, and spends the rest of the session polishing an option that was never the best one available.

The problem is not that the underlying system is probabilistic. It is that the interface hides the fact. There was a spread of plausible answers; you were shown one, and told nothing about the shape of the rest.

Ask the same open question five different ways and you will get five materially different answers. That is not a malfunction. It is a map of the space you are actually deciding in. The variance is the finding.

Where the answers converge, the question is more settled than you thought and you can move on. Where they diverge, your judgement is genuinely required - and that is exactly where a human in the loop earns their place. This inverts the usual instinct. Rather than tuning for a single best output, tune for a useful spread, then spend scarce human attention on the disagreement.

Once you accept that the goal is not a correct answer but a better decision, the collaboration pattern changes shape. Five rules cover most of it.

1. 01

   Generate variance on purpose

   Ask for genuinely different approaches, not three rewordings of one: opposed constraints, different framings, an adversarial pass against the leading option. Variance is cheap to produce here and very expensive to skip.

2. 02

   Humans supply criteria, not answers

   The scarce input is taste - what "good" means for this company, this client, this decision. Written down, it becomes reusable context. In subjective work, codified judgement is the proprietary layer, in the same way structured data is the proprietary layer in factual work.

3. 03

   Iterate rather than specify

   In deterministic work, specification precedes execution. In subjective work you discover the specification by looking at attempts. Optimise for the cost and speed of a round, not for getting the brief right first time.

4. 04

   Keep the discarded options

   Rejected branches are the record of why a decision was made. Six months later they are frequently worth more than the answer that won, and they are the thing almost every team throws away.

5. 05

   Judge by movement, not correctness

   The question after a working session is not "was it right" but "am I further along than I would otherwise be". An answer that was wrong but surfaced the real constraint beats a correct one that told you what you already knew.

The two modes want opposite things from the system and from the people using it.

Almost every real workflow contains both. A proposal has a determinate part - pricing, prior work, contract terms - and a subjective part: framing, argument, what to leave out. The practical skill is noticing the seam between them and switching posture as you cross it.

Both failures are recognisable. Teams that run everything in verification mode never produce anything interesting; they optimise a process nobody chose. Teams that run everything in exploration mode eventually send a client a number that is not true.