Assumptions and Risk

In plain words

Before a college fest stall, you argue about the banner and forget to ask whether anyone will walk to that corner. Software works the same way. Under every feature list sit a few quiet bets, and if one is false the rest does not matter. So list the bets, score each on damage, doubt and how hard it is to undo, then spend your next afternoon testing the scariest one in the cheapest way you can.

How it flows

A tiny example

bets = load_assumptions()
for b in bets:
    b.risk = b.impact * b.uncertainty + b.irreversible
open_bets = [b for b in bets if b.evidence is None]
open_bets.sort(key=lambda b: b.risk, reverse=True)
test = cheapest_test_for(open_bets[0])
print(test.threshold, test.if_pass, test.if_fail)

Notice the threshold and both next decisions are written down before the test is ever run.

What you will learn

• How to turn a feature idea into the bets hiding inside it.
• How to write an assumption that can actually be proved wrong.
• Why risk needs three separate scores, not one gut feeling.
• How to pick the next thing to test by risk instead of excitement.

The problem, simply

Think of a college fest. Your team decides to run a food stall. Everyone jumps straight to the fun part: menu, banner design, who will sit at the counter, what music will play.

Nobody asks the boring questions. Will students walk to that corner of the campus? Will the college allow a gas stove? Will the ₹8,000 come back? Will anyone still be hungry at 4 pm?

Each of those is a bet. If even one of them is false, the banner design does not matter at all. And you find out on fest day, with the money already spent.

Now put an agent in place of the stall. Say your team wants an agent that reads production alerts and tells the on-call engineer which service broke. The plan looks like a neat list of features. Underneath, the team is quietly betting that the alert text even names a service, that engineers will trust a suggestion they did not work out themselves, that the logs can be read without dangerous access, and that this kind of incident happens often enough to be worth maintaining.

See, a roadmap hides all of that inside the word "build". An assumption map drags it out into the open.

The idea

Every build is a stack of bets

An assumption is a thing that must be true for the work to deserve your time. It is not a task. "Add a Slack button" is a task. "Engineers will act on a suggestion they did not derive themselves" is an assumption.

There are five useful families to check yourself against:

• Value — will the outcome matter enough to anyone?
• Usability — can the user understand it and act on it?
• Feasibility — can the system actually produce this with the data and limits we have?
• Viability — can the team afford to run, own and maintain it?
• Safety — if it fails, can we survive the failure?

Most teams list two or three value assumptions and stop. The ones that kill projects are usually feasibility and safety.

Write it so it can be proved wrong

"The feature is useful" is not an assumption. It is a mood. You cannot run any test that makes it false.

Compare: "Eight out of ten on-call engineers identify the correct service faster when they see the agent's read-only suggestion." Now there is a group of people, something you can observe, a number, and a clear way to fail.

IMPRemember: if you cannot describe the result that would make you abandon the idea, you have not written an assumption yet.

Risk is three numbers, not one

Score every assumption on three things, say from 1 to 5:

• Impact — how much damage if this turns out false?
• Uncertainty — how weak is our evidence right now?
• Irreversibility — how expensive is it to learn this the hard way, after we have committed?

A common way to combine them is impact times uncertainty, plus irreversibility. That formula is not sacred. You could use another one. The point of keeping the three separate is that the team must say out loud why one unknown should be settled before another.

A worked example

Suppose Priya's team is building that incident agent. She writes four assumptions and scores them.

The top one wins. And notice it is also the cheapest to test: Priya takes thirty past alerts, reads them by hand, and counts how many actually contain a service name. No code, no deployment. One afternoon.

If only nine out of thirty contain it, the whole agent idea changes shape before a single line is written. That is the entire value of doing this first.

Design a test that can say no

A weak experiment only proves the team can build the thing. A useful one has a claim that could be false, a realistic sample, an observable result, a threshold fixed before you look, and a stated next decision for pass, fail and unclear.

That last part matters most. If "fail" and "pass" both lead to "so we continue building", you did not run a test. You ran a demo.

Warning

Warning: The moment you see the result before fixing the threshold, your brain will move the threshold. Write the number down first, in a place other people can see.

Reversibility changes the order

Two bets can score the same and still deserve different treatment, because one can be undone and one cannot. So put the cheap, undoable learning first. Replay old incidents in read-only mode before touching a live integration. Use a temporary adapter before migrating a database. Ship a suggestion that a human approves before letting the agent act on its own.

Basically, the shape of your build should follow the shape of your uncertainty.

Build it

This script keeps a small assumption map, scores it, separates what has been tested from what is still open, and tells you what to test next.

# assumption_map.py — rank open assumptions and pick the next test.

def score(a):
    """Impact x uncertainty, plus the cost of learning too late."""
    return a["impact"] * a["uncertainty"] + a["irreversible"]

def falsifiable(a):
    """A weak check: a real assumption names a number and a group."""
    text = a["claim"].lower()
    return any(w in text for w in ["out of", "%", "per ", "within", "zero"])

assumptions = [
    {"claim": "Alert text names the service in 25 out of 30 past alerts",
     "kind": "feasibility", "impact": 5, "uncertainty": 4,
     "irreversible": 1, "evidence": None},
    {"claim": "8 out of 10 engineers act on the suggestion in replay",
     "kind": "usability", "impact": 4, "uncertainty": 4,
     "irreversible": 2, "evidence": None},
    {"claim": "Agent makes zero writes to production during replay",
     "kind": "safety", "impact": 5, "uncertainty": 2,
     "irreversible": 4, "evidence": None},
    {"claim": "The suggestion feels modern and clean",
     "kind": "value", "impact": 3, "uncertainty": 3,
     "irreversible": 1, "evidence": None},
    {"claim": "This incident type happens at least 4 times per week",
     "kind": "viability", "impact": 3, "uncertainty": 3,
     "irreversible": 1, "evidence": "checked 6 weeks of tickets: 5 per week"},
]

# Anything we cannot prove wrong is not an assumption. Flag it, park it.
vague = [a for a in assumptions if not falsifiable(a)]
open_bets = [a for a in assumptions if a["evidence"] is None and a not in vague]
open_bets.sort(key=score, reverse=True)

print("Vague, rewrite before scoring:")
for a in vague:
    print("  -", a["claim"])

print("\nOpen bets, riskiest first:")
for a in open_bets:
    print(f"  [{score(a):>2}] ({a['kind']}) {a['claim']}")

nxt = open_bets[0]
print("\nTest this next:", nxt["claim"])
print("If it passes -> build the bounded slice.")
print("If it fails  -> reframe the idea, do not just retry.")
print("If unclear   -> widen the sample once, then decide.")

Run it and look at three things. The vague claim gets thrown out before it ever gets a score. The viability bet already has evidence, so it disappears from the queue. And the safety bet sits third even though its impact is 5, because we are fairly sure about it already — that is uncertainty doing its job. Now set evidence on the top bet and run again; watch the next test change.

Where you will see this

• Startup teams deciding whether to build an AI feature at all, before hiring for it.
• Security reviews for agent tools, where the safety assumption is written first and tested read-only.
• Coding agents like Claude Code or Cursor rolling out in a company: first suggestion-only, then apply-with-approval, then automatic edits.
• Customer-support bots, where teams replay old tickets offline before letting the bot answer a single live customer.
• Any product team that runs a small pilot on one campus or one city before a nationwide launch.

Common mistakes

• Listing tasks instead of assumptions. "Build the retriever" is work you will do. It tells you nothing about whether the work is worth doing.
• Writing claims you cannot fail. "Users will love it" survives every possible result, which means it teaches you nothing.
• Collapsing risk into one gut number. A high-impact bet you are already confident about needs different handling from a low-impact bet you know nothing about. One number hides that.
• Testing the easy assumption first. It feels productive, and it burns the week where you could have discovered the project has no data to stand on.
• Deciding the threshold after seeing the data. Then every result becomes a pass, and the test was theatre.

If they ask in an interview

Q: How do you decide what to build first in an AI feature?

A: I write down the conditions that must be true for the feature to be worth building — value, usability, feasibility, viability and safety. I score each on impact, uncertainty and irreversibility, and then attack the highest open risk with the cheapest test that could prove it wrong. Feature order follows the risk order, not enthusiasm.

Q: What makes an experiment decisive rather than a demo?

A: A decisive test has a claim that could turn out false, a realistic sample, a threshold fixed before the result, and a stated next step for pass, fail and unclear outcomes. If every outcome leads to "keep building", it was never a test.

Q: Why does reversibility change your build order?

A: Because an irreversible commitment, like a data migration or giving an agent write access, is very expensive to learn from after the fact. So I put reversible learning first — read-only replays, human-approved suggestions, temporary adapters — and only take the irreversible step once the evidence supports it.

Try these

1. Pick any feature you want to build and write five assumptions for it, one from each family. Rewrite any that cannot be proved wrong.
2. Add one safety assumption your original feature list did not mention. Most lists skip it.
3. For your top-scored assumption, write the exact threshold that would make you stop the project. Show it to a friend before you test.
4. Replace your biggest planned experiment with a cheaper one that answers the same question. Counting by hand over past data usually works.

Words, simply

Quick recap

• Every build is a stack of bets; write them as claims a result could prove wrong.
• Score impact, uncertainty and irreversibility separately, so the ordering has a stated reason.
• Test the highest open risk with the cheapest sharp test, and fix the threshold before you look.