The evaluation period
Send the records to the formats you exchange today, read what each report says, settle and verify, and, if you choose, observe one decision flow.
Send it to today's formats
sdc-mapper is the shared core of the Governed Data Record mappers. It validates a record, reads the model the record names, resolves every value against what the model says about it, and hands the result to a mapper for one format. Three mappers ship with it:
sdc-gdr2ubl
OASIS UBL 2.3, with Peppol BIS 3 as profiles. Output validates against the UBL schemas.
sdc-gdr2edifact
UN/EDIFACT D.24A: ORDERS, ORDRSP, DESADV, RECADV, INVOIC and REMADV.
sdc-gdr2omop
The OMOP Common Data Model 5.4, with concepts looked up in your own Athena vocabulary download.
Agents are the primary caller: sdc-mapper-mcp is an MCP server that takes one record at a time, as records arise, and returns the output, its report and one plain sentence saying what the format could not hold, so the agent can act at once. Every call is appended to a hash-chained log that holds identifiers, counts and hashes, never values.
Where the model does not settle how a value reaches a format, a mapping file does. It is YAML, bound to one model version and one format version, cites its rules by component, and is refused for any other version, so a mapping never drifts silently. A partner's conformance profile is a mapping file layered on the base mapping.
What every report says
Every value in the record appears in the report, with its class:
- lookup: the model already binds the format's code, or the format's location follows from the value's type
- declared: a rule in the mapping file places it
- carried: written to a note or source-value field the format provides for that purpose
- not representable: the format cannot hold it
Each Exceptional Value is reported too, as preserved (the format has an exact code), degraded (a coarser code, naming what merged), carried (as text in a field the format defines) or lost. A rejected value is never written as a value, and nothing processed goes unrecorded.
Outputs and reports are byte-stable: the same record, model, mapping file and mapper version produce the same bytes. Each format is credited for what it can express; the report states a format's limits as properties of the format, not as faults.
The declared count
The declared values are the work every organization does today, from its own databases into each format it exchanges, and does again whenever a rule, a profile or the standard changes. Over the evaluation period you watch that count for your own data. It is the cost of the present way, measured. When the Governed Data Record itself is what partners exchange, there is no mapping to maintain and nothing lost between the application's data model and the exchange format.
Settle and verify
A decision made over a Governed Data Record can be settled with a Receipt: a signed record naming the parties by the keys each publishes, the record and the model by their hashes, and the decision. Anyone holding a Receipt verifies it offline with pip install sdcreceipt, with no account and without asking the system that made it.
During the evaluation, settle a handful of decisions over your own records and have someone outside the team verify them. The Verifiable Settlement Layer page describes the format.
The optional governance track
If governance evidence matters for one of your decision flows, run sdcgovernance beside it for the 30 days. Every time a decision occurs, the engine evaluates the DMN decision table you authored against the Governed Data Record involved, reading rule inputs and provenance evidence from the ProvGov layer. The outcome is a hash-chained Receipt of the decision, the rule that fired and the state at the moment of evaluation. The track is observational: it does not gate, block or change the flow.
Every governance Receipt logs:
decision: PERMIT, DENY, INDETERMINATE or NOT_APPLICABLE (XACML 3.0)reasoning: which rule fired and whystatus_code: a XACML URN for evaluation statusinstance_idandinstance_version: the Governed Data Record evaluatedtimestamp: when the decision happenedprevious_hash: the receipt_hash of the prior Receipt in the chaindimensions_checked: which fields the rule read, named by their ProvGov component identifierserrors: any evaluation problemscontext_hash: SHA-256 of the evaluation context that produced the decisionreceipt_hash: SHA-256 of the Receipt content (RFC 8785-aligned canonicalization)
A typical governance Receipt is 1 to 2 KB; a flow of 1,000 decisions a day produces roughly 30 to 60 MB over the period. Keep them on local disk, in object storage or in a SQL table.
The rhythm of the 30 days
Compose the model from the public components, point the agents at the source, validate the first records and put them in your storage. Run each format's mapper on a few records and read the first reports.
Write or adopt the mapping file for each format, layering a partner's profile where you have one. The declared count settles as the rules settle. Where a value is not representable, decide whether that matters for the partner who receives it.
Records flow from the source as they arise, are validated, stored, mapped and logged. Settle a handful of decisions with Receipts. If the governance track is running, its Receipts accumulate without day-to-day attention; INDETERMINATE outcomes mark the places a rule could not reach a verdict.
Run sdc-map log summary --days 30 | sdc-map log verify to check the mapping log's chain. Have someone outside the team validate a sample of records and verify the Receipts, offline. If the governance track ran, run verify_chain() on its corpus.
Put the numbers together (next page) and decide.
Operating posture
- Read-only against your systems. The evaluation produces new artifacts beside production and changes nothing in it.
- Append-only logs. The mapping log and the governance chain are hash-linked; an edited or deleted entry shows.
- No values in the logs. Records carry personal and commercial data; the logs hold identifiers, classes, codes and hashes only.
- Little attention once running. After the mapping files settle, the records and reports accumulate without daily work.