nativeExchangeStart with the interface package.
Find the path to a working Exchange Client.
Native helps turn scattered specifications and samples into a reviewable build. The first win is seeing every file we need, proving its layout, and finding the few decisions that matter—before anyone spends days wiring fields by hand.
A package with three moving parts
Imagine a vendor sends a specification, two sample files, and a note about an outbound acknowledgement. The names below are invented for this walkthrough.
Know the work before building the work.
- Catch a missing import or export early.
- Spend less time translating layouts into Exchange configuration.
- Separate a parsed file from a correctly mapped account.
- Take only material unanswered questions back to the client.
- Keep a record of what was assumed, reviewed, and proved.
Explore the four gates
Each gate adds a different kind of certainty. Select a gate to see what a reviewer would inspect and what remains unresolved.
Prove the physical shells
Review the proposed imports and exports, then confirm each layout against a real sample. A shell can load and parse while its destination fields remain deliberately unmapped.
Proposed interface inventory
Each item points back to the document or sample that suggested it. The reviewer confirms that the inventory is complete.
The Gate 1 proof asks
The pictured statuses explain the proof; they are not results from a live customer file.
Map meaning before columns
Native can propose a meaning using the specification, samples, and Tribal knowledge. A familiar field name alone never establishes an account key, balance bucket, or payment event.
Example semantic trail
The question marks are intentional. A reviewer needs to know whether this identifies an account, identifies a customer, or has another role.
One question worth asking
“When the reference is missing or matches more than one Latitude account, should this record reject?”
That answer changes business behavior. It belongs in a recorded decision, with its source and scope, before a mapping is approved.
Handle the rules around the layout
Some integrations need transaction translations, reversals, special rejects, post-processing, reconciliation, or customer-specific behavior. Those rules are reviewed separately from the physical shell and core mapping.
Rule review, not guesswork
Tribal plus customer context
Tribal provides shared Latitude and Exchange knowledge. Customer-specific configuration is a separate layer; nativeInsights can contribute that context when subscribed. Neither should silently turn a historical example into a universal rule.
Prove the result, not just the file
Run controlled examples in a test Latitude environment and compare what actually happened with what the interface required. A Client that loads successfully has only passed an early check.
Expected versus observed
Evidence that travels with the build
Keep the input, approved interpretation, generated Client, execution receipt, expected result, observed result, and any remaining variance together. Only then can the interface be called behaviorally validated.
This walkthrough illustrates the acceptance method; it does not report a completed customer test.
A useful Gate 1 start
For supported, explicitly reviewed layouts, nativeExchange can generate unmapped shells and check physical parsing with the installed Latitude Exchange library. Source names remain evidence, not approved Latitude mappings.
The path to a working integration
Document completeness, semantic mapping, customer rules, and full Latitude behavior depend on the actual interface. We surface gaps and decisions early, then prove the result through testing.