An assumption becomes expensive through reach
A small rule can enter a design, API, database, client application, report, and support process before anyone challenges it.
The repair then includes migration, compatibility, communication, and customer recovery. The original line of code might be the cheapest part.
Look for assumptions early because reach grows with each dependent decision.
Search common assumption boundaries
Ask whether identifiers are unique forever, time zones align, names fit one format, networks respond in order, and retries are harmless.
Check who owns a record after a user leaves, what happens when an external service responds late, and how partial work is reversed.
Domain experts often know exceptions that examples omit. Include support, operations, security, finance, and legal context when consequences reach them.
Turn assumptions into testable statements
Write the assumption and the evidence source. Then describe a counterexample and the effect it would have on users or data.
For example, the system assumes one email address belongs to one person. A shared family address or recycled workplace address challenges that rule.
A focused experiment can reveal whether the behavior is intentional, accidental, or undefined. Bring that result back to design before expanding coverage.
Keep an assumption record small
Record only assumptions with meaningful consequence or uncertainty. Include owner, evidence, decision, review trigger, and related product area.
Review the record when integrations, regulations, user groups, or data models change. An old valid assumption can become a new defect source.
The goal is not exhaustive documentation. It is earlier visibility for quiet decisions that can become difficult to reverse.