Make implicit source assumptions visible
Two exports can use the same column name for different concepts. Order date may mean creation time in one system and requested ship date in another. A numeric amount may be gross in one source and net in another. A transformation contract should record these meanings before mapping fields, joining records or generating aggregates.
The workflow design starts with a bounded source schema and target definition, followed by a candidate mapping checked against fixtures. Explicit rules should cover null values, time zones, decimal precision, key uniqueness and reject handling. Schema-compatible output can still be semantically wrong, so the checks must reach beyond parsing.
Constrain the execution surface
For a query-oriented task, the application should supply approved data access and an execution policy. A model-generated query is untrusted until validated and run within those limits. A read-only analysis contract must not gain write access because a generated statement asks for it.
Use bounded result sizes and runtime limits appropriate to the destination. Verify join cardinality, preserved identifiers and aggregate reconciliation against the accepted source snapshot. If source tables change between planning and execution, record that drift and decide whether to reject or re-evaluate the candidate.
| Check | Failure it can expose |
|---|---|
| Expected row relationships | A join unexpectedly multiplies records |
| Null and reject counts | Records disappear during conversion |
| Amount reconciliation | Precision loss or incomplete grouping |
| Stable source references | Output cannot be traced to its input |
| Allowed operations | Generated code exceeds the task boundary |
Choose whether the outcome is an artifact or a write
An exported, checked dataset is a different outcome from an updated production table. Start with a reviewable artifact when mappings are new or the destination lacks a safe recovery mechanism. If writes are later authorized, define transaction boundaries, conflict handling and post-write reconciliation separately.
A pilot should include malformed dates, duplicated business keys, unexpected enums and a source-column change. Retain rejected records with reasons so an apparently clean output does not hide missing work. The expected result is a transformation whose assumptions and exceptions can be inspected, not a claim that generated SQL is automatically correct.
Missing a detail or found a problem?
Send a documentation question →