Assumption tracking: the part of a decision that expires

Every meaningful technical decision rests on a set of conditions that were true at the time. We will stay under a few thousand users. This vendor is the cheapest option. The team has Rust experience. Traffic is regional. None of these are permanent, and none of them announce their own expiry.

Assumption tracking is the practice of writing those conditions down as separate, checkable statements attached to the decision they support — so that when one changes, you can find every choice that was built on it.

Why prose is not enough

Most teams do record their reasoning somewhere. The problem is that it is recorded as narrative: “we picked this because we expect low write volume and the team knows Postgres.” That sentence contains two assumptions, but as prose neither can be checked, neither can be queried, and neither can trigger anything. Eighteen months later write volume is forty times higher, and the sentence still sits there reading like a justification rather than an expired warranty.

What a tracked assumption looks like

• Stated as a claim that can be true or false — "peak write volume stays under 500/sec", not "performance should be fine".
• Attached to the decisions that depend on it, so one change surfaces everything affected.
• Given an owner, because an assumption nobody is responsible for is a note, not a control.
• Re-checked on a schedule, rather than only when something has already broken.
• Able to be marked broken — which should flag the decisions above it rather than silently editing history.

The compounding problem

A single stale assumption is a manageable annoyance. The damage compounds because decisions build on other decisions. You chose a queue because of an assumption about throughput; you then chose a deployment topology because of the queue; you then chose a monitoring stack because of the topology. When the original throughput assumption breaks, three layers are resting on it and nothing in the system connects them.

This is the difference between a decision log that is a historical archive and one that is an early-warning system. The archive tells you what you thought. The warning system tells you when what you thought stopped being true.

Where Ecko fits

When Ecko extracts a decision from a PR thread or a Slack conversation, it pulls out the assumptions underneath it as separate tracked items rather than leaving them buried in the text. Those get re-checked on a schedule, and when one stops holding, the decisions that depend on it are flagged and their owners hear about it — before the plan quietly stops making sense.