Governed domain models

A domain model in CDC is more than a schema. It is the unit that governance, ownership, and auditability attach to, the place where the platform’s control guarantees become concrete for a specific slice of enterprise data. This page covers what that means for an evaluator: how the model catalogue decouples consumers from source systems, how governed data is stored so that history is never lost, and how identity and sensitivity are expressed as first-class facts.

For the mechanics of the pre/post-hook enforcement and the audit trail these models feed, see the governance and audit model.

A catalogue independent of any source system

CDC maintains a central catalogue of domain models: named, typed data structures (a Customer, an Order, a Supplier) described by their properties and the relationships between them. The catalogue is authored and owned inside CDC, deliberately independent of the schema of any source system.

This independence is the foundation of the data-control layer. A consumer, whether analytics, an integration flow, an AI application, or a new digital product, depends on the governed model, not on how Customer happens to be shaped in the ERP today. When the ERP is upgraded, replaced, or joined by a second system that also holds customer data, the governed model stays stable and the dependency does not break. Source systems can evolve underneath a fixed contract; that is what a control layer buys.

Models are versioned and follow a Draft → Published lifecycle. A published model is immutable, so a consumer reads against a fixed structure; changing a model means publishing a new version, and the platform tracks which version any given record and reference was written against. References between models are supported (an Order referencing a Customer), including cyclic relationships, so the catalogue can express a genuine data graph rather than a flat list of tables.

Governed data is an event log

Governed data is not stored as mutable rows that get overwritten. The first time an entity is committed it is recorded as a Created event; every subsequent change for the same identity is an Updated event that merges into the entity’s current state. The platform maintains current state separately for fast reads, but the full event history is preserved behind it.

For an evaluator, the significance is traceability by construction:

• Nothing is silently overwritten. The history of how an entity reached its current state is intact and replayable, which is what makes the audit trail meaningful: a change is a recorded fact, not a lost prior value.
• Reads and history are separable. Consumers get efficient current-state reads without giving up the ability to reconstruct or audit past states.
• Lifecycle is reversible where it must be, and terminal where it should be. A model can be retired from new use (archived) without destroying the data written under it (existing records stay readable and in-flight work still completes), and physical deletion is permitted only where no data ever existed. Data that once existed is never quietly removed.

Identity: deciding what is new versus an update

Because CDC ingests records from many systems that each key the same real-world entity differently, every model declares an identity strategy: how the platform decides whether an incoming record is a brand-new entity or an update to one it already holds. The default strategy maintains a mapping from a source system’s own identifier to CDC’s stable entity identity, keyed so that the mapping survives re-publishing the process that feeds it. A single entity can therefore carry several source-system identities at once (its identifier in the ERP and in the PIM), and records from either system merge onto the same governed entity.

This is the mechanism by which the data-control layer produces one governed view of an entity across a fragmented source landscape, the core promise of master-data-style governance, rather than a pile of disconnected per-system copies. Identity is expressed declaratively on the model, so how an entity is recognised is itself a governed, versioned decision.

Sensitivity and ownership are model facts

Governance rules need something to attach to, and models provide it. Properties carry attributes that the platform treats as governed facts, not comments:

• Sensitive: the property holds personal or confidential data and is masked in logs and the UI.
• Encrypted: the property is protected in transit and at rest.
• Read-only: the property must not be modified by process tasks.
• Owner: the team or system accountable for the property.
• Identity: the property that carries a source system’s identifier for the entity.

Because sensitivity and ownership are declared on the model, policy decisions at the governed boundaries (masking a field on egress, restricting who may read an entity, enforcing which region may process it) have a stable, machine-readable basis. An evaluator assessing whether CDC can enforce their data-classification or ownership regime is really asking whether these facts can be expressed once, on the model, and enforced everywhere the data moves. They can.

Why this matters for adoption

The governed model catalogue is where the abstract promise of a “data control layer” becomes assessable:

• It gives consumers a stable contract that outlives any individual source system.
• It produces a single governed entity from records scattered across systems, via declared identity.
• It records data as preserved history, so audit and lineage are real rather than aspirational.
• It carries sensitivity and ownership as first-class facts, so governance policy has something concrete to enforce.

Together these let an organisation put accountability and control around enterprise data without freezing the systems that produce it, the value the data-control layer exists to deliver.