Loading reference model…
This is the Interactive Explorer for an implementation-ready reference data model for privacy programs, inspired by W3C DPV. Use the sidebar to browse the 12 capability areas, the entity and relationship catalogs, the risk-discretionary decisions, the maturity delta map, or the spatial graph. The model is regulation-agnostic at its core and indexed by your target CMMI maturity level per domain. Hover the small info icons on any control to see a short explanation, or hover any dotted term in body text for its definition.

An implementation-ready privacy data model

A regulation-agnostic core spineCore / spine. The non-negotiable backbone of the model. Every implementation has these entities and relationships, at every maturity level., maturity-gatedMaturity-gated. Only required as your privacy program becomes more mature. The reference model adds these structures as you advance through CMMI levels. periphery, and risk-discretionaryRisk-discretionary. Defensible either way. The right choice depends on your organization's risk tolerance for that domain. decisions — organized across twelve privacy capability domainsCapability area (domain). One of the 12 privacy program functions the model decomposes — for example, Processing Inventory, Consent Management, Risk Assessment. Each can have its own maturity level. and the five CMMI capability levelsCMMI levels. L1 Initial (ad-hoc), L2 Managed (a register exists), L3 Defined (the spine is assembled), L4 Quantitatively Managed (versioned, time-bound, evidence-tracked), L5 Optimizing (continuous, automated)..

Model at a glance
The reference model decomposes privacy programs into 12 capability areas. The table below shows what each area covers and where it sits in the model (deeply modeled, lightly modeled, or interface-only). Click any row to drill into the entities, decisions, profile overlays, joins, and maturity ladder specific to that area.

Domain browser

Twelve privacy capability areasCapability area (domain). One of the 12 privacy program functions the model decomposes — e.g., Processing Inventory, Consent Management, Risk Assessment. Each can have its own maturity level.. Click a row to drill in.

ID Name Description
Domain #

DPV anchor:

Core entities (this domain)

Key decisions

Profile overlaysRegulation profile. A regulation-specific overlay on top of the regulation-agnostic core. Each chip is a profile whose mandatory fields, named instances, or report templates touch this domain.

No profile overlays touch this domain.

Cross-domain joinsCross-domain join. A relationship that spans two capability areas. These show how the 12 areas connect into one coherent model.

Maturity ladderMaturity ladder. What changes in this domain between adjacent CMMI levels. The L3→L4 step typically dominates the cost, because it adds versioning, immutability, valid-from/to, and edge-level evidence.

Leverage observation

An entity is a thing the model represents — a Processing Activity, a Consent Record, a Personal Data Category, and so on. Filter by capability area, status, maturity, or regulation profile to narrow the list. Click any row to expand the full definition.

Entity catalog

CoreCore / spine. The non-negotiable backbone of the model. Every implementation has these entities and relationships, at every maturity level. entities (C-Exx) plus per-domain originated entities. Click a row for full definition.

Showing of entities
IDID. Stable identifier. C-Exx = core entity; Dn-Exx = entity originating in domain n. Name Definition DomainDomain. The capability area(s) this entity belongs to. StatusStatus. core, maturity-gated, risk-discretionary, or interface. MaturityMaturity. The lowest CMMI level at which this entity is required.
No entities match the current filters.
A relationship connects two entities — for example, a Processing Activity uses Personal Data and pursues a Purpose. Each row shows the from/to entities, the cardinality, whether it is mandatory, and whether DPV already has a property for it.

Relationship catalog

CoreCore / spine. The non-negotiable backbone. Every implementation has these relationships at every maturity level. relationships (C-Rxx) with cardinalityCardinality. How many entities can appear on each side. 1..1, 1..N, 0..1, 0..N, N..M. and obligationObligation. Mandatory, Conditional, or Optional..

Showing of relationships
ID Relationship From To Card. Oblig.
The reference model exposes 40 risk-discretionary decisions (R4C-01 through R4C-40). Each is a point where multiple options are defensible at lower maturity levels and the choice depends on your organization's risk tolerance. The "options and basic considerations" column contextualizes each decision point in two sentences. Two decisions are resolved at v1.0: R4C-11 (Assessment polymorphism) via Charter D14, and R4C-12 (TOM theme classification) via Charter D15. Both rows are retained as historical rationale.

Decision catalog

40 risk-discretionaryRisk-discretionary. Defensible either way; depends on your organization's risk tolerance. decisions where multiple defensible options exist. The model commits a default recommendation and shows how it tightens at higher maturity.

Showing of decisions
ID Decision point Domains Options and basic considerations
This view shows what changes between adjacent CMMI levels for each capability area. The rework catalog at v1.1 covers all four transitions with 102 entries: 49 L3→L4 (the multiplicative structural-retrofit cost — every reified association and accountability artefact gains temporal validity, immutable history, edge provenance, versioning, and attestation), 20 L2→L3 (spine-assembly — typed entities and reified associations introduced per domain), 15 L1→L2 (register-establishment plus 2 cross-cutting class declarations), and 18 L4→L5 (operational-automation — observability, integration, and cryptographic infrastructure built on the L4 data structure). Every entry is tagged with a costCategory: the 49 + 20 = 69 structural-retrofit and spine-assembly items are the schema-rework surface adopters should plan for; the 13 register-establishment and 18 operational-automation items are separate cost lines.

Maturity delta map

Per-domain structural delta between adjacent CMMI capability levelsCMMI levels. L1 Initial, L2 Managed, L3 Defined, L4 Quantitatively Managed, L5 Optimizing. L3→L4 is the costliest jump. with effort ratings.

Leverage observation:
· deltas
items
DomainDomain. The capability area this delta belongs to. TransitionTransition. Which CMMI level jump this delta belongs to. DeltaDelta. A single structural change required to move from one CMMI level to the next. TypeType. entity, relationship, attribute, state, or rule. EffortEffort. Rough effort to implement, shown as 1–3 dots. PrerequisitePrerequisite. Other domain levels that must be in place first.
No deltas recorded for this transition.
A spatial view of the model. Toggle layers to add or remove detail (core spine / per-domain entities / cross-domain joins). Click a node to focus on its neighborhood. Use the focus-mode toggle to switch between dimming the rest and isolating with relayout. Node color encodes capability area; node size encodes status; thick borders mark entities with a DPV mapping; dashed borders mark DPV gaps.

Spatial graph

Force-directed view of the data model. Toggle layers, filter, and click nodes to explore.

Nodes:
Edges:
Focus:
Layout:
Search
Max level
Max L
Status
Layers
Focus
Layout
View
Scroll to zoom · drag to pan · click node for details
Legend
Core (largest)
Maturity-gated · risk-discretionary · interface (decreasing size)
Border: thick = DPV mapping; dashed = DPV gap. Dashed grey edge = cross-domain join.