SIE.7:4 - Solution
Specify semantic mapping rules separately from their implementation. Bind every rule to a receiving-use contract, exact source and target schemes, accepted correspondence premises, and any identity or claim-composition premise on which that rule depends. Make selection, cardinality, conversions, defaults, errors, loss, trace, and tests explicit. Require implementations to preserve these behaviors or return a named discrepancy.
SIE.7:4.1 - Pattern-Use Unfolding
- Name the output claim and receiver. State the target field or proposition, its meaning, grain, interval/effectivity, and the action it supports.
- Bind source and target schemes. Reference exact
SIE.2source rows and target interface/model definitions, editions, profiles, units, codes, identifiers, and access assumptions. - Bind semantic premises. Reference accepted
SIE.4correspondence rows and every load-bearingSIE.5identity disposition. Reference aSIE.6composition or conflict result when the rule depends on that result. Stop on an unresolved required premise; do not require identity or claim-composition work that cannot change the rule. - Specify selection and extraction. State source records, predicates, joins, windows, configuration/effectivity filters, ordering, and behavior for missing or duplicate inputs.
- Specify transformation. State direction, construction, decomposition, aggregation, unit/code conversion, normalization, derivation, and required external lookup. Name the authority for any conversion or code table.
- Specify cardinality and identity preservation. State one-to-one, one-to-many, many-to-one, or conditional behavior; keep source identifiers and disposition references when rows combine or split.
- Specify defaults and errors. Distinguish absent, unknown, not applicable, inaccessible, stale, incompatible, unresolved, source failure, and actual zero or empty value. Permit a default only when the contract and semantic warrant state its meaning and loss.
- State information loss and forbidden reuse. Name omitted distinctions, coarsening, precision, interval, provenance, or conflict and the use for which the loss is accepted.
- Provide trace and examples. Give stable rule identifiers, input-to-output trace positions, positive examples, boundary and counterexamples, and expected negative branches.
- Define implementation conformance and reopen. State observable behavior an implementation must match and source, premise, contract, or target changes that invalidate the rule.
SIE.7:4.2 - Record the Result
| Mapping position | Required content |
|---|---|
| rule and use | stable rule identifier, receiver, output claim, grain, interval/effectivity |
| schemes | source/target assets, models/schemas, editions/profiles, fields/types/relations, units/codes |
| semantic inputs | accepted correspondence rows and any relied-on identity dispositions or composition/conflict results, with their conditions |
| extraction | selection, joins, filters, windows, effectivity, duplicates, missing-input behavior |
| transformation | direction, construction/decomposition/aggregation, conversions, lookups, derivation |
| cardinality and identifiers | source-target multiplicity, split/merge behavior, source-ID and premise preservation |
| defaults and errors | distinguished states, permitted default and meaning, failure branches, quarantine or stop |
| loss and trace | accepted/forbidden loss, provenance, rule and premise references, input-output trace |
| examples and conformance | positive, boundary, negative/unlike examples, expected outputs, implementation predicate, reopen |
SIE.7:4.3 - What Changes in Practice
Semantic decisions leave code and configuration comments and become an independently reviewable specification. Data Engineering can optimize or replace an implementation while preserving the mapping behavior, and a failed output can be traced to a source premise, rule, implementation discrepancy, or receiving-use change.