Compliance Req.

Origin & evolution

Requirements as discrete, traceable obligations come from the control frameworks that decompose a standard into auditable line items. The AICPA's 2017 Trust Services Criteria break SOC 2 into individual points of focus; ISO/IEC 27001 lists controls in its Annex A; the GDPR, enforceable since May 2018, sets specific obligations such as breach notification within 72 hours. Each becomes a requirement an organisation can implement, evidence, and have checked.

The traceability discipline matured alongside compliance-automation tooling. A modern programme links each requirement to the control that implements it and the artefact that proves it, so an auditor can follow the thread from "the framework demands X" to "here is the log that shows X happens".

How it works in practice

A fintech product inherits a GDPR requirement: users can request deletion of their personal data. That single requirement constrains three things. It blocks a proposed analytics feature⭐FeatureProduct SpecificationA product capability or featureView reference → that would have copied user records into an un-purgeable warehouse. It forces a decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → to add a deletion API rather than handle requests manually. And it generates an evidence trail (deletion logs) that the next audit samples. The requirement did real work by saying no to one feature and reshaping another.

Compliance Requirement vs. its neighbours

• Compliance Framework🏟️Compliance FrameworkComplianceA compliance framework (SOC 2, GDPR, etc.)View reference → is the named regime the requirement comes from. The framework is the source; the requirement is one obligation it mandates. Trace any requirement upward and a framework is at the top.
• Constraint is the general category of anything that limits design choices. A compliance requirement is a constraint with a legal or contractual origin, which is what gives it teeth that a self-imposed constraint lacks.
• Feature is what a requirement acts on. The requirement does not build the feature; it bounds it, ruling some designs out and forcing others in.

In the graph

In the Unified Product Graph, a compliance requirement sits in the governance and compliance region as the operative unit of constraint. It links up to its source through compliance_framework_mandates_compliance_requirementCompliance FrameworkmandatesCompliance Requirementhierarchy and constrains the product via product_constrained_by_compliance_requirementProductconstrained byCompliance Requirementhierarchy, compliance_requirement_constrains_featureCompliance RequirementconstrainsFeaturecross-domain, and compliance_requirement_constrains_decisionCompliance RequirementconstrainsDecisioncross-domain. Modelling the requirement as something that constrains features and decisions, not just a checklist item, is what lets a team answer the real question: if this control changes, what do we have to rebuild.