Module 1: Semantic Data Fundamentals

1.1 The Floor Constraint Core

Every SMB conversation about "AI" or "data strategy" eventually hits the same wall: the data layer is ambiguous, brittle, or untrusted. You can buy the best model, the slickest BI tool, or the most expensive practitioners - none of it matters if the underlying data cannot be reliably interpreted.

This is why the Maturity Map starts with the foundational dimensions (Schema Integrity, Constraint Enforcement, Semantic Identity) and treats them as gating. A client scoring Level 4 in Governance but Level 1 in Schema Integrity is functionally at Level 1 - the governance is governing chaos.

1.2 Syntactic vs Semantic Interoperability Core

Syntactic interoperability means two systems can exchange bytes. JSON in, JSON out. CSV in, CSV out. The pipes connect.

Semantic interoperability means two systems agree on what those bytes mean. When System A says bp: 120, does System B know that means systolic blood pressure in mmHg, taken seated, on the patient's left arm, by a calibrated cuff, at 9:14am?

Most "integration" projects deliver syntactic interoperability and call it done. Then six months later someone discovers the imported data is unusable because the meaning was lost in translation.

1.3 Why Top-Down Fails Core

The classical enterprise architecture approach: define a canonical model first, then force every system to map to it.

Why it fails in the wild

• The canonical model is always wrong on day one because nobody knows everything about the domain
• Mapping every legacy system is a multi-year project that loses political support before completion
• Real-world data has exceptions the canonical model didn't anticipate
• The model becomes a museum piece maintained by a small team disconnected from the systems that produce data

Top-down is not stupid. It is correct in spirit. It just cannot be executed against a moving target with finite budget.

1.4 Why Bottom-Up Fails Core

The opposite approach: let every system define its own data, then use ML/heuristics to reconcile after the fact.

Why it fails

• The reconciliation problem is exponential in the number of systems
• Probabilistic matches are not auditable for compliance
• New systems require re-training the reconciliation layer
• "Good enough" matches accumulate semantic drift over time

Bottom-up is also not stupid. It respects reality. It just cannot guarantee correctness when correctness matters (regulatory, financial, clinical).

1.5 Two-Level Modeling Core

The synthesis: separate the reference model (stable, slow-changing, generic primitives) from the domain constraints (fast-changing, specific to a use case).

• Reference model: a small set of well-defined primitives - Quantity, Coded Value, Identifier, Time Point, Person. These rarely change.
• Domain constraints: rules that specialize the primitives for a context - "systolic BP is a Quantity with unit mmHg, range 40-300, taken in posture X by role Y."

Domain modelers (clinicians, accountants, lawyers) author constraints in their own vocabulary. The reference model guarantees those constraints compose with constraints from other domains because they all bottom out in the same primitives.

1.6 Minimum Knowledge Models Intermediate

Two-level modeling tells you how to layer a model. It does not tell you how big each layer should be. The second core principle of the SDC approach answers that question.

Most modeling standards - FHIR, NIEM, HL7, SNOMED CT compositional grammar, and many others - try to model concepts maximally. Every possible attribute that might apply to a concept is added to the definition. The intellectual appeal is "we are being thorough." The practical cost is borne by every implementer for the rest of the standard's life: hard to author, hard to govern, hard to query, hard to validate, hard to map.

SDC takes the opposite approach.

A model component captures only what is essential to identify the concept and distinguish it from its nearby concepts.

Not every concept in the universe - just the ones close enough to be confused with it. Specificity beyond that minimum is achieved through composition with other minimum components at use time, not by inflating any single definition.

A concrete example: blood pressure

A maximal model of blood pressure tries to enumerate every cuff type, every patient position, every measurement device, every reference range, every confounding factor - because somewhere, someone needs each of those. The resulting cluster is enormous. Most attributes are never populated for any given measurement. The cluster is hard to author, hard to govern, hard to query, hard to validate, and hard to map to anything else.

A minimum model of blood pressure captures only what makes it blood pressure and distinguishes it from pulse pressure, arterial pressure, or intracranial pressure. Cuff type, patient position, and measurement device are separate components, composed in only when a specific deployment actually needs them. A clinic that never records patient position never deals with the patient-position component. A research study that does compose it explicitly. Both clinic and research study use the same blood pressure component.

Why maximal modeling breaks even with good people

The openEHR Clinical Knowledge Manager (CKM) is a community-driven archetype library built by people who care deeply about correctness. It still depends on a committee-approval workflow for every change. The bottleneck is not bureaucracy - it is the modeling philosophy. Maximal-modeling pressure makes every archetype contentious because every contributor wants to add their specialization, every reviewer wants to defend the boundaries, and the resulting artifact needs human ratification at every step.

SNOMED CT compositional grammar (the IHTSDO post-coordination approach) is the same lesson at industry-standards scale. Beautiful in theory, brutal at the data management layer. Practitioners who have lived through either of these will recognize the pattern immediately and find SDC's discipline liberating.

Where the locus of specificity sits

The deepest implication of minimum modeling: the locus of specificity is composition, not definition. A maximal model puts specificity in the definition - every possible context baked in. A minimum model puts specificity in the composition - you compose blood-pressure + measurement-device + patient-position when and only when you need that specificity.

This is what makes SDC components reusable across engagements in a vertical practice. The minimum components are stable and shared across every client. The compositions are the local variation that captures each client's specific needs. The practitioner's library compounds because the components themselves do not over-fit to any single client.

Why structural identity is decoupled from descriptive labels

A natural failure mode of maximal modeling is to use the descriptive label as the structural identifier. A concept becomes blood_pressure_systolic_seated_left_arm_calibrated_cuff_2023_revision - the label and the structural identity are the same string, baked into every reference, every query, every export. This is convenient until you need to change anything: rename the concept, translate to another language, improve the wording, refine the meaning. Every change breaks every consumer.

The minimum knowledge modeling discipline forced the SDC ecosystem to a different answer. A component's CUID2 is permanently bound to its label. Every component is identified by a CUID2 - a stable, opaque, machine-generated identifier. The label is not a description that can be edited - it is a fixed part of the component's identity. If you need the same concept expressed in a different language or with different wording, you create a new component with its own CUID2. The two components are then reconciled through their shared semantic links to standard vocabularies - for example, both bind to the same SNOMED code or LOINC term. The CUID2 carries the structural identity. The vocabulary bindings carry the cross-component equivalence.

This is what makes component reuse practical. Because a component's meaning is locked at creation - its label, its constraints, its vocabulary bindings - any system that consumes it gets the same semantics every time. With minimum knowledge modeling, most components are simple enough that they never need to change. You model the concept once, correctly, and reuse it everywhere. If your domain needs evolve, you create new components rather than mutating existing ones. The library grows; existing components stay stable.

For practitioners coming from relational databases, EHR systems, or enterprise platforms, this is a fundamental shift. You are accustomed to schema changes breaking downstream systems and triggering expensive migration projects. In SDC, that entire category of problem does not exist.

The principle applied recursively

• At the component level: each component models only what is essential to its concept
• At the assembly level: a data model includes only the components essential to the use case, not every component that might apply
• At the deployment level: the generated application exposes only the workflows the client actually performs

Maximalism at any layer destroys the benefit at every other layer. Minimalism compounds.

1.7 Where SDC Fits Core

The SDC specification (currently at the SDC4 reference model generation) is a concrete, open implementation of two-level modeling that:

• Uses XSD 1.1 + Schematron for structural and constraint enforcement
• Uses RDF/OWL for semantic identity and reasoning
• Uses SHACL for graph-level validation
• Uses JSON-LD for serialization that round-trips through both worlds
• Binds CUID2 sovereign identifiers to every component for traceability
• Stores data and constraints together so they cannot drift

1.8 What You're Building: A Context Graph with Structural Governance Advanced

The industry is converging on the term "context graph" to describe what the enterprise world needs from AI infrastructure. Foundation Capital called it "AI's trillion dollar opportunity." Neo4j is hosting meetups about it. The buzzword is new. The architecture is not.

Interactive version: semanticdatacharter.com/stack.html

A context graph is a knowledge graph that contains all of the information necessary to make decisions throughout an organization. Not just the data - the reasoning behind the data, the authority that produced it, the process that governed it, and the provenance that traces it.

When you build an SDC data model, you are building a context graph. Every model automatically generates RDF/OWL/SHACL representations. Every component carries semantic bindings. Every governance element - workflow state machines, attestation models, party/role components, provenance chains - is structurally present in the graph. This is not a separate build step. It is an intrinsic property of the modeling process.

As Jessica Talisman put it at the inaugural Context Graph meetup: "Context graph is like saying wet water - that's the benefit of graphs." She is right. The industry is discovering what knowledge graphs were always supposed to deliver. SDC delivers it - with governance built in, not added on.

When you talk to clients, use the vocabulary they are hearing from their vendors and conferences: "context graph," "decision traces," "the missing why." Then show them that SDC delivers it structurally, deterministically, and with governance that travels with the data - not in a separate dashboard, not in a vendor's proprietary engine, and not by LLM extraction that requires continuous babysitting.

1.9 Case Study: The $47 Billion Integration Problem Core

(Reference case study - full text in case_studies/integration_cost.html.)

Summary: A 2022 industry analysis estimated US healthcare spends $47B/year on data integration projects that primarily deliver syntactic interoperability. The semantic layer is rebuilt by every vendor, every project, every time. The Maturity Map exists to make this waste visible to a client in 90 minutes.

1.10 Meet Your Client: Atlas Legal Group Core

Throughout this curriculum, you will work with a single fictional client: Atlas Legal Group, a 12-person immigration and small business law firm in the Pacific Northwest. They have the problems every SMB has - client names spelled three different ways across systems, a retiring bookkeeper who is the only person who knows where the data inconsistencies live, a failed $40K vendor migration, and a recent state bar audit finding.

You will meet Atlas Legal's managing partner (Dana Okafor), their informal tech lead (Marcus Chen), the defensive paralegal who built the Access database (Linda Reeves), and the bookkeeper who retires next year (Patricia Kim). You will assess their data, score their maturity, prescribe interventions, deploy SDCforSMB, and build their implementation proposal.

Every concept in this curriculum will be applied to Atlas Legal. When you finish Module 9, you will have a complete, practitioner-quality engagement from intake through proposal - on a case study that mirrors the clients you will actually encounter.

Read the full Atlas Legal intake brief in exercises/case_atlas_legal.html now. You will reference it throughout the remaining modules.

Further Reading

• ISO 13606 reference model overview
• openEHR architectural overview
• W3C Data on the Web Best Practices
• The SDC specification (introduction chapter only for this module)