Obligation Mapping
Translating each legal or regulatory requirement into the specific design constraints it imposes, so that compliance becomes a set of testable properties rather than a document.
Regulation arrives as prose written for lawyers. Architecture needs constraints. Obligation mapping is the translation: for each requirement, what must the system be able to do, prove, prevent or produce.
A row looks like: Article 17, right to erasure → the system must locate all personal data for a subject across every store within thirty days; must delete or render unreadable in each; must produce evidence of completion; and must handle backups under a stated retention position. Those are four design constraints, each testable, each ownable.
Doing this early changes what gets built. Erasure designed in means separating identity from event and encrypting per subject; erasure discovered late means a programme. Residency designed in means region selection and a data flow diagram that stops at a border; residency discovered late means a migration.
The output belongs in the same place as the non-functional requirements, because it is the same kind of thing: a constraint that bounds the design space before options are considered. Kept in a separate compliance document, it is consulted after the design is agreed, which is exactly too late.