Pattern · the lead pattern of three
Jurisdiction-as-Data
ContextA long-lived platform must produce legally correct behavior across many distinct jurisdictions at once (states, countries, counties, regulatory boards), whose rules change on legislative cycles, and a regulator must be able to inspect exactly what the system enforces.
ProblemHow do you build one platform that enforces jurisdiction-specific requirements correctly, without making its core logic depend on the rules of any particular jurisdiction? Encoding the differences as branching code makes the system fragile, expensive to certify, and impossible to scale jurisdiction by jurisdiction.
ForcesFive tensions the solution must hold in balance:
- regulatory precision vs. platform generality
- certification scope vs. jurisdictional coverage
- regulatory velocity vs. engineering velocity
- auditability vs. system complexity
- schema expressiveness vs. schema stability
SolutionModel each jurisdiction's rules as versioned, declarative data the platform reads at runtime. The platform logic stays general; precision lives in the data. The jurisdiction record becomes the certifiable, auditable artifact a non-engineer can inspect, and onboarding a jurisdiction becomes a reviewed data change rather than a code change and re-certification.
Known usesCasino gaming certification · consumer & mortgage lending · real-estate transactions