Module 2: The Six Dimensions of Maturity

Duration: ~120 minutes self-paced Prerequisites: Module 1 Learning objectives: - Define each of the six dimensions in plain language - Identify Level 1-5 indicators for each dimension from artifact evidence - Apply the Floor Constraint Principle to a mixed-score profile - Read and interpret a Maturity Map radar chart

2.1 Overview

The SDC Maturity Map assesses six dimensions, each scored 1-5. Three are foundational (the floor) and three are derived (capped by the foundation).

The floor constraint: A derived dimension cannot exceed the minimum of the three foundational dimensions. A client cannot have trustworthy provenance over data with no schema integrity. They cannot have meaningful interoperability without semantic identity. They cannot govern what they cannot constrain.

2.2 Schema Integrity

Definition: The degree to which data structures are explicitly defined, versioned, and enforced at write time.

What you are looking for: Is there a schema? Is it the same schema everyone uses? Does it change? When it changes, do existing records get migrated or do they silently break?

Levels:

• Level 1 — Ad Hoc: Data lives in spreadsheets and free-text fields. Column names vary between files. No formal definitions.
• Level 2 — Documented: A data dictionary exists somewhere. It is mostly current. Some systems enforce it; others don't.
• Level 3 — Enforced (On Track): A canonical schema is enforced at write time by at least the primary system. Versions are tracked. Schema changes go through review.
• Level 4 — Integrated: All systems share a single source-of-truth schema. Migrations are automated. Schema changes trigger downstream notifications.
• Level 5 — Federated: Schemas compose across organizational boundaries via shared reference models. Cross-org joins work without translation layers.

Evidence to ask for: A copy of the data dictionary. A recent ALTER TABLE log. An example of a field that was renamed and how downstream systems handled it.

2.3 Constraint Enforcement

Definition: The degree to which validation rules travel with the data and execute at the point of writing.

Levels:

• Level 1: Constraints exist only in the heads of long-tenured employees. New hires reinvent them.
• Level 2: Constraints documented in a wiki. Enforced by occasional batch jobs that produce reports nobody reads.
• Level 3: Constraints enforced by the primary system at write time (NOT NULL, CHECK, foreign keys). Violations rejected.
• Level 4: Constraints expressed declaratively (Schematron, SHACL, JSON Schema) and re-used across multiple systems.
• Level 5: Constraints versioned alongside data. Historical records validate against the constraint version that was active when they were written.

Evidence: A constraint document. A query that finds rows violating the documented rules (count > 0 means Level ≤ 2).

2.4 Semantic Identity

Definition: The degree to which every data element has a stable, unambiguous identifier whose meaning does not depend on context.

Levels:

• Level 1: Auto-increment integer IDs scoped to a single database. "Customer 47" means different people in different systems.
• Level 2: UUIDs or GUIDs used in some places. Not universally adopted. Joins still rely on natural keys.
• Level 3: Stable identifiers (UUID, CUID, ULID) used for all primary entities. No reuse after deletion.
• Level 4: Identifiers are URI-formed and dereferenceable within the organization. Cross-system joins use the same ID space.
• Level 5: Identifiers are globally unique, sovereign, and resolvable across organizational boundaries. CUID2-style identifiers bound to data packets.

Evidence: Pull a record. Ask "if I gave this ID to your billing system, would it find the same entity?" If the answer involves a translation table, you are at Level ≤ 2.

2.5 Provenance

Definition: The degree to which every data value can be traced to its origin, author, time, and conditions of capture.

Levels:

• Level 1: created_at and updated_at columns. No author. No conditions.
• Level 2: Audit log captures who-changed-what for some tables. Gaps exist. Logs purged after N days.
• Level 3: Append-only audit log for all sensitive tables. Author, timestamp, and previous value captured.
• Level 4: Provenance graph spans system boundaries. You can trace a dashboard number back through every transformation to the source row.
• Level 5: Provenance is cryptographically signed and tamper-evident. Suitable for regulatory or legal evidence.

Floor constraint reminder: Provenance cannot exceed min(Schema Integrity, Constraint Enforcement, Semantic Identity). You cannot trace what you cannot identify.

2.6 Interoperability

Definition: The degree to which data can cross organizational or system boundaries without reinterpretation.

Levels:

• Level 1: Data shared via emailed spreadsheets. Receiving party manually reformats.
• Level 2: Point-to-point APIs. Each integration is bespoke.
• Level 3: Standard formats (JSON-LD, FHIR, OData) used for at least one interface.
• Level 4: Multiple systems exchange data via shared standards with no per-system mapping layer.
• Level 5: Data carries enough self-description that an unknown receiver can interpret it correctly using only published standards.

Evidence: How long does it take to onboard a new partner? If the answer is "weeks," you are at Level ≤ 2.

2.7 Governance

Definition: The degree to which data quality rules are documented, enforced, audited, and improved over time.

Levels:

• Level 1: No data governance role exists. Quality issues handled ad hoc.
• Level 2: A data steward exists. Policies documented. Enforcement uneven.
• Level 3: Quality metrics tracked. Violations trigger remediation workflows. Quarterly review.
• Level 4: Quality SLAs published. Stakeholders accountable. Continuous monitoring.
• Level 5: Governance integrated with provenance and constraint layers. Policy-as-code. Automated compliance reporting.

The context graph connection: Governance at Level 5 means the client's data carries its own decision traces. Every state transition in a workflow is recorded with who authorized it, under what authority, and what the state of the data was at the moment of the decision. This is what the industry is now calling a "context graph" - a knowledge graph where the reasoning behind decisions is queryable and auditable, not just the outcomes. When you assess a client's Governance dimension, you are measuring how close they are to having a structurally governed context graph vs. a documentation binder that no agent can read.

2.8 Reading the Radar Chart

A Maturity Map produces a six-axis radar chart. Three things to look for:

1. Floor: What is the minimum of the three foundational dimensions? That is the client's effective ceiling on the derived dimensions.
2. Inversion: Are the derived dimensions higher than the foundational ones? That is a red flag — it means the client is investing in the wrong layer.
3. Asymmetry: Big gaps between adjacent dimensions usually indicate organizational silos.

A healthy intermediate client looks like a hexagon with all six points roughly equal at Level 3. An unhealthy one is a star shape with peaks at Governance and Interoperability and valleys at Schema and Identity.

Module 2 Exercise

You receive these scores from a fictional client:

• Schema Integrity: 2
• Constraint Enforcement: 2
• Semantic Identity: 1
• Provenance: 4
• Interoperability: 3
• Governance: 5

Questions: 1. What is the effective ceiling on the derived dimensions? 2. The client is proud of their Governance score. How do you explain to them, without crushing morale, that it is misleading? 3. Which dimension would you recommend they invest in first, and why? 4. Sketch the radar chart. What shape does it form? What does that shape suggest about the organization?

(Discussion guide in exercise_guides/module_2.md.)