Compliance Database Responsibilities¶
Why This Exists¶
This document defines conceptual database responsibilities for the Compliance Domain.
It does not define SQL implementation, migrations, storage technology, or final schemas.
Owner¶
The owner is the Chief Product Officer and Enterprise Architect.
Business Value¶
Clear persistence responsibilities make compliance readiness, expiry, verification, and risk auditable and reusable.
Conceptual Tables Or Collections¶
| Conceptual table or collection | Responsibility |
|---|---|
| compliance_profiles | Organization-bound compliance profile and summary state. |
| compliance_requirements | General compliance requirements. |
| tender_compliance_requirements | Tender-specific requirements and source references. |
| compliance_documents | Uploaded or registered compliance documents. |
| compliance_evidence | Evidence linked to requirements. |
| compliance_verifications | Verification records and outcomes. |
| compliance_expiry_alerts | Expiry monitoring and alert state. |
| procurement_readiness_assessments | Readiness scores and component breakdowns. |
| compliance_risks | Risk records, severity, cause, and remediation. |
| compliance_gaps | Missing or insufficient requirement coverage. |
| compliance_ai_suggestions | AI suggestions and review state. |
| compliance_audit_log | Compliance changes, verification, and review audit records. |
Indexing Considerations¶
Future implementation should consider indexes for:
- OrganizationId.
- ComplianceProfileId.
- RequirementId.
- Document type.
- Verification status.
- Expiry date.
- Readiness score date.
- Risk severity and status.
- Suggestion status.
Audit Requirements¶
Compliance persistence should capture:
- Actor.
- Source.
- Timestamp.
- OrganizationId.
- Previous and new values for compliance status changes.
- Verification reviewer and method.
- AI suggestion provenance.
- Correlation ID.
Ownership Rule¶
Compliance storage is canonical for compliance state. Organization storage remains canonical for company identity.