Use a requirement record
Create a record with the jurisdiction, instrument, provision, scope assumption, application date and source. Include the interpretation adopted for the product and the reviewer who confirmed it. If the interpretation is unresolved, keep that status visible. A requirement record is more useful than a copied paragraph without context because it explains which product facts made the source relevant.
Define an observable control
State the action, responsible role, trigger and intended result. For example, a disclosure control might require a reviewed version to be selected from the document register before a case enters the agreement stage. This is an illustrative design, not a statement of a universal legal requirement. Avoid descriptions such as ensure compliance that cannot be tested or assigned. Record dependencies on systems, intermediaries and manual teams.
Choose evidence that answers the question
Evidence should show whether the action happened and under what conditions. Depending on the control, that may be a delivery event, a reviewed exception, a version reference or a sample result. Specify the location, access rules and retention basis. A screenshot can help show appearance but may not prove which customer received the communication. A database record can show an event but may not reveal whether the content was readable.
Review effectiveness separately from completion
A completed task does not demonstrate that the control works across the relevant population. Review coverage, failures and exceptions. Record the gap, impact question, responsible owner and resolution evidence. Update the map when the legal source, product or operating process changes. This creates a research and audit pathway while leaving the final legal assessment to the appropriate reviewer.
Primary sources
Demonstration source register ↗Illustrative source pathway.