Regulatory Constraint as Architectural Driver
A compliance obligation that removes design options entirely, and therefore belongs among the first constraints identified rather than checked at the end.
Regulatory requirements differ from other non-functional requirements in one decisive way: they are non-negotiable and non-tradeable. You cannot accept 95% compliance with a residency requirement in exchange for lower latency. That makes them constraints that bound the design space rather than qualities to be optimised.
The ones that most often eliminate options: data residency, which forces a regional partitioning that touches identity, routing and every data store; retention and erasure obligations, which constrain immutable and append-only designs; auditability, which requires evidence generation to be designed in; segregation of duties, which shapes deployment and access architecture; and exit requirements, which constrain how deeply managed services can be adopted.
The failure pattern is universal and expensive: the architecture is designed for the functional and performance requirements, compliance is engaged for review before launch, and a constraint surfaces that invalidates a foundational choice. At that point the options are a costly redesign, a schedule slip, or a waiver that the organisation carries as risk.
The professional practice is to identify regulatory constraints in the same conversation as the functional requirements, treat them as architectural drivers of equal standing, and involve compliance and legal at design time rather than at review time. That is usually a matter of asking early rather than of any additional effort, and it is one of the highest-leverage habits available in regulated environments.