The Architecture Stack
From upper ontology to governance enforcement. 8 layers. Each one constrains the layer above it. Click any layer to explore.
BFO 2020 - Upper Ontology
ISO/IEC 21838-2:2021 - The structure of reality
The philosophical foundation. BFO distinguishes continuants (things that persist through time - patients, organizations, devices) from occurrents (things that happen - processes, events, activities).
SDC inherits this distinction: data components are continuants, workflow activities are occurrents. This isn't arbitrary taxonomy - it's the structure that makes cross-domain interoperability possible.
SDC-BFO Alignment
Mapping SDC concepts to BFO categories
Maps every SDC Reference Model type to its BFO category. XdString is a generically dependent continuant (information that can be copied). A workflow Activity is a process (an occurrent that unfolds in time).
This alignment is why SDC models are philosophically coherent, not just structurally valid. Two independently built domain models interoperate because they share the same ontological foundation.
SDC Meta-Ontology
How modeling works - ModelComponent, CMS, CMC
The meta-ontology defines the modeling process itself. A ModelComponent is a domain concept constrained by the RM. A CMS (Constrained Model Structure) is a data model. A CMC (Constrained Model Component) is a single constrained element.
This is the layer that makes restriction-based modeling work. Every domain model is a restriction of the RM types - never an extension. New components are created by constraining, not by inventing new structures.
SDC Reference Model
The building blocks - 20+ base types
The type system. Every data model restricts these types:
Gold-colored types are governance components built into the DMType root. Data types (teal) and governance types (gold) coexist in the same model.
Domain Model
Built in SDCStudio - what your data means
The practitioner or domain architect builds this layer in SDCStudio. Source data (CSV, Markdown, PDF, JSON) is ingested, AI extracts candidate components, and the practitioner binds them to domain ontologies via vocabulary links.
Every component is a restriction of an RM type - constrained with enumerations, regex patterns, value ranges, cardinality. The BFO alignment is inherited. The domain semantics come from the vocabulary bindings.
Output formats: XSD, RDF/OWL, SHACL, JSON-LD, GQL schemas.
Data Instance
The actual data - carries its own meaning
An XML document conforming to the domain model's XSD. The instance carries: instance_id (CUID2), current-state (workflow position), subject/provider (party identity), workflow (state machine), Audit[] (provenance), attestation (authority).
The governance IS in the instance. Extract it from any platform and the meaning, constraints, and governance travel with it.
sdcvalidator
Structural validation - deterministic pass/fail
Single-pass structural validation. Instance against schema. Data types correct? Required elements present? Constraints satisfied? Deterministic. No interpretation.
Two-tier error classification: structural (Tier 1) vs semantic (Tier 2). Available on PyPI. MCP server for agent integration.
Independent from sdcgovernance - agents call each library separately.
sdcgovernance
Governance advisory - 24 standards, XACML decisions
Governance advisory engine implementing 24 standards from W3C, OASIS, OMG, ISO, IETF, IANA. Returns OASIS XACML decisions: PERMIT, DENY, or INDETERMINATE.
Workflow (SCXML state/transition concepts on XdOrdinal cluster trees), Attestation (W3C VC pattern), Provenance/Audit (W3C PROV-O + DPV retention), Decision Tables (OMG DMN), Cross-entity constraints (W3C SHACL).
Every decision produces a SHA-256 hash-chained receipt. Tamper-evident. Append-only. Deterministic.
MCP server (raw JSON-RPC 2.0, no SDK dependency). 225 tests in 0.22 seconds.
Each layer constrains the one above it. The meaning is structural, not inferred.
24 standards. 6 standards bodies. One data substrate.