Prerequisites

The substrate-and-monitor architecture

SDC inverts the standard governance assumption. Most governance frameworks observe outputs after the fact, classify them post-hoc, and call the classification governance. SDC puts the constraint in the data: the boundaries and semantics travel with the data the model is reading from, so the constrained output is the only output in the distribution.

The audit is what makes the substrate visible. Receipts are the record of governance happening, not governance being applied after the fact.

The two component layers

An SDC instance composed for governance has two component layers, not one. Pilots that miss this distinction usually model the first layer well and then wonder what the audit is supposed to observe.

• Domain data components: what your records are. People, organizations, encounters, claims, filings, transactions. Sourced from NIEM, FHIR, NIH CDE, or the Default library, depending on your vertical.
• ProvGov components: what makes those records governable. Workflow states, provenance, attestation, party and role, decision-table inputs and outcomes, retention, validation hashes, and access-control tags. Each family is anchored to a public standard: W3C PROV-O, W3C Verifiable Credentials 2.0, W3C SCXML, W3C DPV, OMG DMN.

The audit observes the second layer running over the first. Without ProvGov components in the model, there is nothing standards-anchored for sdcgovernance to evaluate against and no tamper-evident chain for the validator to confirm. The next page covers both component layers in detail.

What you actually need before the audit starts

• One decision flow you want to observe. Pick the one where governance evidence matters most: a regulated approval path, a financial decision, a clinical recommendation, a procurement gate.
• Validated SDC4 instances flowing through that decision flow, composed from both component layers above. The next two pages of this guide cover how to produce them in a day or two.
• A DMN decision table that mirrors the rules the flow already follows. The table reads from the ProvGov layer (risk score, classification, actor role, attestation status, retention class). Authoring it is part of the setup and stays short for most pilots.
• An SDCStudio account with a small wallet balance funded. Most pilot projects spend less than $20 across the full audit period.
• sdcgovernance installed: pip install sdcgovernance. Apache 2.0, on PyPI.

The SDC Reference Model (SDCRM)

SDCRM is the canonical specification all SDC libraries implement against. It defines the structure, semantics, and validation rules that an SDC instance must satisfy. When this guide says "SDC instance," it means a structured payload conformant to SDCRM.

You do not need to read SDCRM cover-to-cover to run a pilot. The agents and the public component libraries handle conformance for you. SDCRM matters when you want to verify that the substrate is what you think it is, or when you want to extend a public component for a domain-specific use case.

Why "no SDC, no audit"

sdcgovernance evaluates DMN decision tables against SDC instances and reads governance evidence from the ProvGov layer inside those instances. Every Receipt it produces references instance_id and instance_version, plus the provenance activity, attestation, party, and entity-state hashes the ProvGov components carry. Without SDC instances composed from both layers, there is no substrate to observe and no Receipts to generate.

This is the part most governance vendor pitches skip past. They promise governance over arbitrary data, then deliver post-hoc classification of arbitrary data. SDC requires the substrate first. The good news is that the substrate setup is now genuinely small: pick domain components from one library, layer ProvGov components on top, validate.

Wallet funding and operating cost

SDCStudio uses a wallet-funded account model. The agents call out to SDCStudio APIs as they introspect, map, validate, and generate against the public component libraries. Those calls draw down the wallet.

Most pilot projects spend less than $20 across the full audit period. Same procurement bucket as a small SaaS trial. Fund the wallet before pointing the agents at your data sources so the introspection step does not stall mid-run.

What the wallet ultimately buys is a downloadable artifact set: the composed data model, a template SDC4 instance, and an Apache 2.0 app stack scaffolded for the stack profile you pick. FOSS profile: Apache Jena/Fuseki + PostgreSQL. Enterprise profile: Graphwise GraphDB + SirixDB + Keycloak. Or both.

After the on-ramp completes, those artifacts are yours, deployable on your own hardware with no further SDCStudio dependency. Every later app you generate imports into the original stack, so the portfolio grows into one shared substrate runtime instead of replicating infrastructure per pilot.