Prerequisites

What a Governed Data Record is

A Governed Data Record is one record of data, conformant to the SDC4 Reference Model (SDCRM), in which every value sits in a component with a published, immutable definition: its type, units, allowed codes, valid range and semantic links. The record names the model it conforms to by an identifier and by its schema's SHA-256, so anyone holding it can check it against the exact bytes it was made against. Its canonical serialization is an XML instance validated against W3C XSD 1.1.

That is what makes the rest of the evaluation possible. Because the meaning is bound to the record, the record can be stored anywhere, written into other formats with every value accounted for, and read by an agent without guessing.

The two component layers

• Domain components: what your records are. People, organizations, orders, invoices, encounters, claims, filings. Most are built from open standards: NIEM, FHIR, NIH CDE, UBL and GS1, Peppol, UN/EDIFACT, ISO 20022, GS1 EPCIS, DICOM, FOCUS and others.
• ProvGov components: what makes those records governable. Workflow states, provenance, attestation, party and role, decision-table inputs, retention, validation hashes and access-control tags, each anchored to a public standard (W3C PROV-O, W3C Verifiable Credentials 2.0, W3C SCXML, W3C DPV, OMG DMN).

The domain layer is all the core evaluation needs. Add the ProvGov layer if you run the optional governance track (step 5), where sdcgovernance reads it.

What you need before day one

• One data source. A SQL table, a CSV export, a JSON feed or a MongoDB collection, read-only or a copy. Pick one whose data you also exchange with someone, so the formats in step 4 mean something to you.
• The formats you exchange today. UBL (and Peppol profiles), UN/EDIFACT, or the OMOP Common Data Model. For OMOP, your own download of the vocabularies from OHDSI's Athena, under their terms.
• Somewhere to keep the records. Any storage you already run: an object store bucket, a document database, a file share.
• An SDCStudio account with a funded credit balance for composing the model. Most evaluations spend fewer than 20,000 credits ($20 worth).
• Python 3.12 or later for the open tools: pip install sdcmodeler sdc-agents-smb sdcvalidator sdc-mapper sdc-gdr2ubl sdcreceipt, plus sdc-gdr2edifact or sdc-gdr2omop for those formats.
• For the governance track only: one decision flow to observe and a DMN decision table that mirrors the rules it already follows.

The SDC Reference Model (SDCRM)

SDCRM is the specification every SDC library implements. It defines the structure, semantics and validation rules a Governed Data Record must satisfy. You do not need to read it to run an evaluation; the components and the agents handle conformance. It matters when you want to check that the records are what we say they are, or to extend a public component for your own use.

Credits and operating cost

The public model components are free to reuse. SDCStudio is paid for with credits, bought in advance at 1,000 credits per US dollar, and composing a model and generating its package spend them. Most evaluations spend fewer than 20,000 credits ($20 worth). Buy credits before pointing the agents at your source so introspection does not stall mid-run.

Everything after the model runs on your own machines under Apache 2.0: the agents, the validator, the mappers, the Receipt verifier. Validating, mapping and verifying spend no credits.

What you keep is the composed model, your records, the outputs in each format with their reports, and an Apache 2.0 app stack scaffolded for the profile you pick: a fully FOSS profile (Apache Jena/Fuseki with PostgreSQL), an Enterprise profile (Graphwise GraphDB with SirixDB and Keycloak), or both. Every later app you generate imports into the original stack, so infrastructure is procured once across the portfolio.