Compliance Aggregates

Why This Exists

This document defines aggregate boundaries for the Compliance Domain using Domain-Driven Design.

Aggregates protect consistency for compliance profiles, requirements, documents, evidence, verification, readiness scoring, expiry, and risk.

Owner

The owner is the Chief Product Officer and Enterprise Architect.

Compliance owns these aggregate boundaries. Organization remains the owner of company identity.

Business Value

Clear aggregate boundaries protect the integrity of procurement readiness and prevent other domains from changing compliance state directly.

Aggregate Catalogue

Aggregate	Purpose	Boundary
Compliance Profile	Root aggregate for an Organization's compliance state.	Organization-bound compliance status, readiness, and risk summary.
Compliance Requirement Set	Set of general or tender-specific requirements.	Requirement definitions, applicability, and satisfaction criteria.
Compliance Evidence Register	Documents, evidence items, expiry, and evidence status.	Evidence records and document validity.
Verification Case	Verification workflow for evidence or requirement satisfaction.	Verification process, result, reviewer, and audit.
Readiness Assessment	Procurement Readiness Score and component scoring.	Score inputs, calculation result, and readiness gaps.
Compliance Risk Assessment	Risk identification and prioritization.	Risk state, severity, cause, and remediation.

Aggregate Diagram

flowchart TD
    Profile[Compliance Profile]
    Requirements[Compliance Requirement Set]
    Evidence[Compliance Evidence Register]
    Verification[Verification Case]
    Readiness[Readiness Assessment]
    Risk[Compliance Risk Assessment]
    Org[OrganizationId Reference]

    Org --> Profile
    Profile --> Requirements
    Profile --> Evidence
    Evidence --> Verification
    Requirements --> Readiness
    Evidence --> Readiness
    Readiness --> Risk
    Verification --> Risk

Core Invariants

Invariant	Description
Organization reference required	Compliance profiles must reference OrganizationId.
Compliance owns status	Readiness, verification, expiry, and risk state are owned by Compliance.
Expired evidence cannot be current	Expired documents must not satisfy current requirements without exception policy.
Verification is explicit	Verified status requires a verification record.
AI suggestions are not facts	AI suggestions require approved Compliance commands before state change.

Transaction Boundaries

Compliance profile updates should be transactional within Compliance. Cross-domain changes should use commands and events rather than direct writes.

Referencing From Other Domains

Other domains reference:

• ComplianceProfileId.
• ComplianceRequirementId.
• ComplianceEvidenceId.
• VerificationCaseId.
• ReadinessAssessmentId.
• ComplianceRiskId.

They must not own Compliance state.