Pilot Pattern
The 30-Day Evaluation
Your data, end to end, on your own storage, in thirty days. Define it once, bring one source in, keep the records wherever you choose, send them to the formats you exchange today, and see what that costs, measured on your own data.
Agents are going to read your data
Today an agent reading your data infers what each field means from whatever format it arrives in. Every agent does it, every time, and with ten source formats it makes ten guesses. Its reasoning is probabilistic, and so, today, is its reading of the data.
A Governed Data Record gives your agents one deterministic thing to execute against. Each value is bound to a published definition, the model it conforms to is never edited, and validation is a yes or a no. The same record and the same model give the same verdict, every time, checkable by anyone. The agent's reasoning stays probabilistic; what it reasons over does not.
Your agents should execute against what your data means, not what they guess it means.
Why the next migration should be the last
Most organizations keep their data in a shape one vendor's application defines. The vendor sets the maintenance deadlines. Leaving, or simply upgrading, means a migration priced in years, and every migration rebuilds the meaning of the data from scratch, because the meaning lived in the application.
That happens because three things are kept apart: where the data is stored, the format it is exchanged in, and the application that defines what it means. Whoever owns the definitions owns the data.
Your next migration should be the last time you migrate meaning.
What the evaluation does
Six steps, on one of your own data sources, in parallel with what you run today. Nothing in production changes.
Define it once
Compose the model for one domain from the free public components with sdcmodeler or SDCStudio, and model what is left.
Bring your data in
SDC_Agents read one of your existing sources (SQL, CSV, JSON, MongoDB) and write validated Governed Data Records. A missing or unusable value is recorded as an Exceptional Value, never guessed.
Keep it anywhere
The records are open formats in your own storage: any cloud, any document store, a bucket. The validator runs offline and needs nothing of ours.
Send it to today's formats
sdc-mapper writes the same records as UBL, UN/EDIFACT or OMOP and reports every value: how it got there, or that the format cannot hold it.
Settle and verify
Decisions made over the records produce Receipts anyone can check offline with sdcreceipt. The governance track is optional.
Day 30: decide with evidence
Your own declared count per format, what each format could not hold, the validation outcomes. You keep everything either way.
The number you take away
When sdc-mapper writes a record into a format, it reports every value in one of four classes. Lookup: the model already binds the format's code, so placing the value needs no rule. Declared: a rule in a mapping file places it. Carried: the format has no structured place for it, so it goes into a note or source-value field the format provides. Not representable: the format cannot hold it.
The declared count is the work every organization does today, from its own databases into UBL, UN/EDIFACT or OMOP, and does again whenever a rule, a profile or the standard itself changes. At day 30 you see that count for your own data, format by format. It is the cost of the present way, measured.
The horizon is the record itself. When the Governed Data Record is what partners exchange, the application's data model and the exchange format are the same thing: no loss of fidelity between them, and no mapping to maintain. The evaluation shows you both sides of that line on your own data.
Why this works as a pilot
Zero production impact
The agents read one source, read-only and enforced: SQL is limited to SELECT, files are never modified, and each agent is isolated to its own purpose. The records, the mapped outputs and the Receipts are produced alongside what you run; nothing your systems do changes.
An empirical exit
At day 30 you hold validated records, the formats written from them, a coverage report for each, and the declared count. The decision rests on measurements of your own data.
Procurement-defensible
The model components are free. The tools (sdcmodeler, SDC_Agents, sdcvalidator, sdc-mapper and its mappers, sdcreceipt, sdcgovernance) are Apache 2.0. The only two costs are a minimal SDCStudio account (typically under 20,000 credits, $20 worth) and your own team's time.
Yours to keep
The composed model, the records, the mapped outputs, the reports, the Receipts and the generated Apache 2.0 app stack stay with you whatever you decide. None of them needs us to stay readable.
The full guide
1. Prerequisites
What a Governed Data Record is, what you need on day one, and what it costs.
2. Define it once
The free public component libraries, 9,822 components on production, and how a model composes from them.
3. Bring your data in, and keep it anywhere
SDC_Agents from one existing source to validated records, stored in open formats wherever you choose.
4. The evaluation period
Send the records to today's formats with sdc-mapper, read the coverage reports, settle and verify, and the optional governance track.
5. Day 30: reading the results
Your declared count, what each format could not hold, and the decision you make with it.
Thirty days, one data source, your own storage
and a measured answer to what your present way costs.
Start with the prerequisites