Constraint Documentation

Overview

Every architecture lives inside boundaries it did not choose: a budget, a data-residency law, an existing database, a three-person team. Constraint documentation lists those boundaries explicitly and distinguishes them from assumptions, which are beliefs that might be wrong. The goal is that no design option is judged without knowing the walls around it.

How it works

Keep a simple register, one row per constraint or assumption, owned by a named person.

ID   Type        Statement                    Source     Fixed?  Review
C-01 regulatory  EU user data stays in EU     legal      yes     yearly
C-02 technical   must integrate with ERP SOAP vendor     no      Q3
A-01 assumption  peak load under 5k req/s     product    n/a     next launch

Each design record cites the constraints it respects. When a constraint is marked negotiable, the register states who can renegotiate it and at what cost, which turns a hidden limit into an explicit option.

Pitfalls

• Mixing assumptions with constraints. An assumption needs a validation plan and a trigger for revisiting.
• Treating every limit as immovable. Some constraints are historical accident.
• Omitting the source. Without an owner, nobody can confirm or relax the constraint.
• Writing it once at kickoff and never again.
• Capturing only technical constraints and missing organizational ones such as skills, on-call capacity, or procurement lead time.

Key takeaways

• Separate constraints from assumptions and mark which are negotiable.
• Name a source and owner for each entry.
• Link constraints to the decisions they shaped.
• Review the register at every major planning point.