Compliance & Regulatory Metadata Model

ELI5

A customs form for every parcel shipped: you declare what’s inside (PII types), who’s allowed to receive it (data residency regions), how long customs must keep the copy (retention), and which trade agreements cover the shipment (compliance frameworks). The form travels with the parcel — auditors can read it even if the parcel is sealed.

Technical Deep Dive

ComplianceRecord (in proto/protocols/vest.proto) attaches regulatory metadata to every VESTProof and AuditEntry. It has five sub-messages.

ComplianceFramework

Declares which regulatory frameworks the entry satisfies and their current compliance status:

Status transitions: PENDING_REVIEW → COMPLIANT or NON_COMPLIANT.

Data Residency

Specifies primary storage region, allowed/prohibited regions, cross-border transfer flag, and the legal mechanism (adequacy decision, SCC, BCR, explicit consent, DPF) enabling cross-border flow.

Retention Requirements

flowchart TD
    A[Entry Created] --> B{legal_hold?}
    B -->|yes| C[Block deletion\nregardless of policy]
    B -->|no| D{DeletionPolicy}
    D -->|AUTOMATIC| E[Auto-delete after max_retention]
    D -->|MANUAL| F[Require admin action]
    D -->|ARCHIVE| G[Archive before delete]
    D -->|CRYPTO_SHRED| H[Destroy encryption key\nGDPR Right to Erasure]

legal_hold = true blocks all deletion regardless of deletion_policy. This is a metadata field — enforcement is application-layer.

Privacy Markers

PrivacyMarkers catalogues PII presence and purpose:

• pii_types: NAME, EMAIL, PHONE, ADDRESS, SSN, FINANCIAL, HEALTH, BIOMETRIC, LOCATION, IP_ADDRESS
• legal_basis: CONSENT, CONTRACT, LEGAL_OBLIGATION, VITAL_INTERESTS, PUBLIC_INTEREST, LEGITIMATE_INTERESTS

RegulatoryFlag

Open-ended extensibility mechanism — a (flag_type, flag_value, effective_date, optional expiry_date) tuple. Allows adding jurisdiction-specific annotations without modifying the core schema.

Key Terms

• CRYPTO_SHRED → DeletionPolicy variant; renders data unreadable by destroying the encryption key rather than deleting the ciphertext
• legal_hold → bool field in RetentionRequirements; blocks all deletion when true
• 21 CFR Part 11 → FDA regulation requiring electronic records to be trustworthy, reliable, and equivalent to paper records; maps to COMPLIANCE_FRAMEWORK_TYPE_21_CFR_PART_11
• DataTransferMechanism → legal basis for cross-border data transfer (SCC, BCR, adequacy, consent, DPF)
• RegulatoryFlag → extensible key-value tag with temporal validity range

Q&A

Q: Which field controls whether data can leave its primary storage region? A: DataResidency.cross_border_allowed (bool) plus transfer_mechanisms list specifying the legal mechanism for any allowed transfers.

Q: How is GDPR Right to Erasure implemented when data is encrypted at rest? A: By setting deletion_policy = CRYPTO_SHRED — the encryption key is destroyed, making the ciphertext permanently unreadable without requiring physical deletion of the stored bytes.

Q: Does compliance_status = NON_COMPLIANT prevent an entry from being written to the log? A: No — ComplianceRecord is metadata stored alongside the proof. Write acceptance is not gated on compliance status; it is informational for auditors.

Examples

A ComplianceRecord snippet for a HIPAA-covered healthcare document operation:

ComplianceRecord {
  frameworks: [
    ComplianceFramework { HIPAA, ["164.312(b)"], COMPLIANT, last_audit: 2026-01-15 },
    ComplianceFramework { SOC2, ["CC6.1", "CC7.2"], COMPLIANT, last_audit: 2026-01-15 }
  ],
  residency: DataResidency {
    primary_region: "us-east-1",
    allowed_regions: ["us-east-1", "us-west-2"],
    cross_border_allowed: false
  },
  retention: RetentionRequirements {
    min_retention: 6 years,
    max_retention: 7 years,
    deletion_policy: ARCHIVE,
    legal_hold: false
  },
  privacy: PrivacyMarkers {
    contains_pii: true,
    pii_types: [HEALTH, NAME],
    legal_basis: LEGAL_OBLIGATION
  }
}