Define source and destination meanings, test six fictional rows and assign an owner to unresolved transformations before any live import.
Two systems both have a field called “duration.” One stores decimal hours; the other expects whole minutes. Connecting fields by name would turn a ninety-minute request into something entirely different.
Before building an integration, write down the meaning of each transferred field and what should happen to values that do not fit. A field map is a small contract between two systems and their owners. It needs business definitions as well as technical types.
The following exercise uses fictional equipment-hire planning tools. It imports nothing, calls no API and makes no reservation.
Put the definitions side by side
The source tool collects a draft request. The destination tool prepares work for staff review. Neither system’s example state means a customer booking is confirmed.
| Source field and meaning | Destination field and meaning | Proposed mapping |
|---|---|---|
| duration_hours: decimal hours requested | duration_minutes: positive whole minutes | Multiply by 60; reject a non-whole-minute result pending policy |
| item_code: fictional catalogue identifier | equipment_id: destination catalogue identifier | Use an approved lookup; unknown code goes to review |
| collection_mode: collect or delivery_requested | fulfilment_route: pickup or delivery_review | Translate allowed values; do not mark delivery approved |
| notes: optional free text | staff_note: optional text | Review scope and permitted content before transfer |
A matching data type is not enough. Both collection fields could be strings while describing different business states. The map must preserve what a person would understand from the value.
Make the missing-value rule explicit
For this example, duration is required before the destination can create a review item. If it is missing, leave the source request available and place it in a clarification queue. Do not turn missing duration into zero minutes or an invented default.
Distinguish a field that is absent, an explicit null, an empty string and a legitimate zero where zero is permitted. JSON Schema’s object reference explains that a null value differs from an absent property, and that required properties must be declared explicitly. Your actual vendor’s schema and business rules still determine what each state means.
For the fictional duration field, zero is invalid because the request requires a positive duration. For another field, zero could be a real value. Avoid one universal “replace blanks with zero” rule across the integration.
Test six rows before connecting anything
Write an expected result for each row before examining an implementation:
- 1.5 hours, known item, collect: maps to 90 minutes, approved destination item ID and pickup.
- 0.5 hours, known item, delivery_requested: maps to 30 minutes and delivery_review; no delivery approval implied.
- Missing duration: no destination review item; clarification reason recorded against the source reference.
- Zero hours: reject for this field’s positive-duration rule.
- 1.333 hours: multiplication produces 79.98 minutes; hold for the agreed rounding policy rather than silently changing it.
- Known duration, unknown item code: hold for catalogue mapping review; do not guess the nearest name.
These are expected fictional transformations. A completed table is a specification, not evidence that an integration passed.
Decide how partial failures behave. If one line in a multi-item request has an unknown code, does the whole request wait or can clearly identified lines proceed? Record the owner who can decide. A developer should not have to infer that policy from whichever API call happens to succeed first.
Week 44 · interactive local candidate
Preserve meaning across the field boundary
Fictional local exercise. This exercise keeps its working inputs in page memory and starts over on reset or reload. It does not automatically submit or save those inputs, call an AI or access accounts. Copies and printouts are outside reset; browser-managed history, extensions and device behaviour are outside this exercise’s control. Use invented examples only; do not enter personal records or credentials. No real transfers or independent verification are performed.
Map draft requests to staff-review items. Hours become positive whole minutes; STAND-N maps to EQ-NARROW and STAND-W to EQ-WIDE. Collection becomes pickup; requested delivery becomes delivery_review. A transformed row never confirms a booking.
Review pending. Change inputs, then review the current version. Earlier results are cleared after every edit.
Week 44: Preserve meaning across the field boundary
Fictional local exercise. This exercise keeps its working inputs in page memory and starts over on reset or reload. It does not automatically submit or save those inputs, call an AI or access accounts. Copies and printouts are outside reset; browser-managed history, extensions and device behaviour are outside this exercise’s control. Use invented examples only; do not enter personal records or credentials. No real transfers or independent verification are performed.
All observations and checks below are fictional or reader-reported; none independently verified.
FIXED FICTIONAL EXERCISE CONTEXT
{
"source": "Fictional draft request; no confirmed booking.",
"destination": "Fictional staff-review item; no reservation or delivery approval.",
"duration": "Plain decimal hours times 60 must yield positive whole minutes. No silent rounding.",
"catalogue": {
"STAND-N": "EQ-NARROW",
"STAND-W": "EQ-WIDE"
},
"collection": {
"collect": "pickup",
"delivery_requested": "delivery_review"
},
"missing": "Absent, null and empty are distinct; required duration stays held. Zero is invalid for this field.",
"notes": "Scope and permitted content need review before any transfer."
}
CURRENT INPUTS (fictional / reader-entered)
{
"rows": [
{
"label": "90-minute collection",
"presence": "value",
"hours": "1.5",
"item": "STAND-N",
"mode": "collect"
},
{
"label": "Delivery request",
"presence": "value",
"hours": "0.5",
"item": "STAND-W",
"mode": "delivery_requested"
},
{
"label": "Missing duration",
"presence": "absent",
"hours": "",
"item": "STAND-N",
"mode": "collect"
},
{
"label": "Zero duration",
"presence": "value",
"hours": "0",
"item": "STAND-N",
"mode": "collect"
},
{
"label": "Fractional-minute result",
"presence": "value",
"hours": "1.333",
"item": "STAND-N",
"mode": "collect"
},
{
"label": "Unmapped catalogue code",
"presence": "value",
"hours": "1",
"item": "UNKNOWN",
"mode": "collect"
}
],
"notes": "",
"notesRule": "hold",
"partial": "unresolved",
"owner": "",
"sourceVersion": "Fictional draft-request v1",
"destinationVersion": "Fictional staff-review v1",
"recordRule": ""
}
Review pending. No current result; any earlier review was invalidated by input changes.
LIMITATIONS AND WARNINGS
• This is a fictional mapping specification and deterministic rehearsal, not a live API, import, reservation or duplicate-prevention test.
• The approved lookup is invented: STAND-N → EQ-NARROW; STAND-W → EQ-WIDE. Real catalogue identity requires its owner.
• Null, absent and empty are distinct source states. Zero is invalid for this duration; zero may be legitimate in other fields.
• Mapping owner, schema versions, repeat-record rule or partial-failure policy is unresolved; this is an incomplete specification.Use the text-only exercise
The complete unchanged manuscript remains readable if the controls are unavailable.
Return to Test six rows before connecting anythingAdd the evidence an implementer needs
For each mapping, retain the source schema version, destination schema version, unit, allowed values, required status, transformation rule, rejection rule and responsible business owner. Link to current official vendor documentation once the actual products are known.
Keep example rows fictional while resolving the design. An access token is not part of a field map. A screenshot of production customer data is not required to explain a unit conversion.
Also identify the record key and version. When the same source request is encountered again, the integration needs an approved rule for identifying an existing record versus creating a new one. That behaviour belongs in the implementation plan and test cases; a clean field map alone does not prevent duplicates.
Inspect the meaning after the transformation
Ask a colleague to read a mapped destination row and explain the customer’s request. Can they distinguish requested delivery from approved delivery? Can they identify which duration was supplied and which conversion produced the stored value?
If the explanation changes, return to the mapping. A technically valid row can still misrepresent the task. Keep rejected rows visible to an appropriate owner with a useful reason, rather than discarding them silently or showing a success count that excludes failures without explanation.
Agree the handover before a live import
Close the exercise with a mapping specification, test rows, expected results and unresolved policy questions. Have the implementer test it in an authorised isolated environment, then compare observed outputs with the specification. Review privacy, access, error recovery and operational ownership before any production connection.
The practical win is a shared definition of what crosses the boundary. That makes integration work easier to inspect and gives failures a specific place to go.
Primary sources checked 4 October 2026
Sources & review
Primary sources checked on . The checklists and planning examples are AI-assisted editorial guidance, not source quotations or reported client results.
This AI-assisted guide uses fictional examples for practice. It does not report client results or establish that a live system will behave the same way.
Originally published: .