When documenting solution options for a technical decision, you list both 'constraints' and 'assumptions' separately. What's the practical difference between the two, and why does conflating them cause problems later?

## What a constraint is In a solution proposal, a **constraint** is a boundary condition imposed on the decision from outside -- something the architect does not get to choose or negotiate away within the scope of this decision. Typical sources include: - regulatory or legal requirements (e.g., data must stay within the EU under GDPR) - an already-signed vendor contract - a fixed budget ceiling set by finance - an existing piece of infrastructure the organization has already committed to - a hard deadline mandated by an external party like a regulator or a major customer contract Constraints define the boundary of the solution space: any option that violates a real constraint should be eliminated outright, not merely scored lower, because by definition it isn't actually viable regardless of how well it performs on other dimensions. ## What an assumption is An **assumption**, in contrast, is a belief the architect is choosing to treat as true for the purpose of the analysis, without it being externally imposed or guaranteed. Common examples include: - an estimate of expected traffic volume - a belief that the team can pick up an unfamiliar technology quickly enough - an expectation that a dependent team will deliver an API integration on a certain timeline - a guess about how a third-party service will behave under load Assumptions carry risk precisely because they might be wrong, and if a load-bearing assumption turns out false, the trade-off analysis built on top of it may no longer hold -- an option that looked clearly superior under the assumed conditions might not be superior at all under the real ones. ## Why they demand different handling The practical reason to separate these two carefully, rather than lump them together as 'things we're taking into account,' is that they demand different handling. - **Constraints** should be sourced and cited -- traced back to the contract clause, the regulation, or the budget document that established them -- and then simply respected; arguing with a real constraint inside a solution proposal is a waste of effort, since the constraint isn't the proposal's to change. - **Assumptions**, by contrast, should be flagged by risk level. A high-risk assumption -- one that's genuinely uncertain and would flip the recommendation if it turned out false -- deserves an owner, a concrete way to validate it (a load test, a spike, a direct confirmation from the dependent team), and ideally a stated trigger for revisiting the decision if it's later invalidated. Low-risk, low-impact assumptions can be listed briefly without that machinery. ## What conflating them costs The failure mode from conflating the two runs in both directions. - **A real constraint treated as a mere assumption** can get silently 'assumed away' by someone optimizing for a different outcome -- a team eager to ship the cheaper option might casually write 'we're assuming multi-region failover isn't required' when in fact a signed enterprise contract legally mandates 99.95% uptime with cross-region disaster recovery; treating that legal obligation as a soft, debatable assumption rather than a hard constraint leads to choosing an architecture that later has to be expensively reworked once the contractual obligation surfaces, often during an audit or a customer escalation, at a much worse time to discover it than during initial design. - **An assumption treated as an immovable constraint**, running the other way, shuts down legitimate exploration -- if 'we assumed peak load stays under 500 requests per second' was never actually confirmed with the business and gets treated as a hard requirement nobody questions, the team may over-engineer for a number nobody actually committed to, spending real effort and calendar time solving a problem that doesn't exist. ## Assumptions that calcify There's also a subtler, longer-timescale failure: assumptions that go unrevisited tend to calcify into de facto constraints simply through repetition. An assumption stated once in an early design document gets copied into subsequent proposals as background context, and after being repeated enough times without anyone re-checking its source, the organization starts treating it as a given, even though it was never validated by anyone and nothing ever actually promised it. This is why periodically revisiting long-lived assumptions -- especially just before a major re-architecture decision that depends on them -- matters: it's the mechanism that catches an assumption before it silently becomes an unexamined, unfounded constraint that shapes years of subsequent architecture without anyone remembering to question it. ## A worked scenario A concrete scenario: a team designs a checkout system. - The stated **constraint** 'must comply with PCI-DSS', sourced from the company's payment processor agreement -- non-negotiable. - The stated **assumption** 'peak Black Friday traffic will be roughly 3x normal daily peak' -- an estimate from the data team, flagged high-risk, with a load test scheduled before launch to validate it, and an explicit note that the horizontal-scaling option becomes necessary if the real multiplier exceeds 4x. Keeping these visibly distinct means that when the load test later shows 5x rather than 3x, the team already has a documented trigger telling them exactly which part of the design needs to be revisited, rather than having to re-derive the whole trade-off analysis from scratch under time pressure.