Integration diagrams make enterprise systems look cooperative. Boxes have clear names, arrows point in one direction, and every event appears to arrive once.
Production data is not like that.
A TMS, WMS, carrier feed, CRM, and support platform may all describe the same shipment differently. They may disagree about its identifier, status, time zone, or latest state. Some systems send events. Others provide snapshots. A spreadsheet export may be the only practical interface for an important part of the workflow.
An operations agent cannot reason reliably until that disagreement is handled.
TMS ─────────┐ WMS ─────────┤ Carrier ─────┼──> Source mapping ──> Shared event ──> Operational case CRM ─────────┤ │ │ Email ───────┤ └── Source history └── Decisions Spreadsheets ┘
The shared event is not an attempt to replace the source systems. It is the smallest common representation the selected workflow can trust. Source history stays available because agreement is never perfect and disputed cases need to be traced back.
Separate what happened from the business detail
Proxima’s shared event has two jobs. One part describes what happened: its identity, source, timing, and place in a case. The other carries the business facts needed by the selected workflow.
These event-level facts remain stable across domains. The business details are defined by the workflow pack. A shipment event may need a promised delivery time and latest ETA. An invoice event may need purchase order, invoice, tax, and receipt amounts.
This split allows the runtime to handle routing, deduplication, tracing, and case correlation without understanding every business field.
Event time and processing time are different facts
Operational data often arrives late. A carrier outage may cause several status updates to appear together. A daily export may describe events that occurred hours earlier.
For that reason, Proxima records when the event occurred separately from when it was received.
The first answers when the business event happened. The second answers when Proxima learned about it. Business-clock SLAs are usually measured from occurrence time; receipt time still drives latency measurement and source-health monitoring. Collapsing them into one timestamp produces believable but incorrect metrics.
Out-of-order events require another decision. A late in_transit event should not overwrite a newer delivered state simply because it was processed later. The case model needs ordering rules based on event time, source authority, and event type.
Identity needs more than one system’s ID
The source record ID helps an engineer find the original record. It is not always the right key for the case.
One carrier may use an airway bill number, the order system may use an order ID, and the support tool may use a ticket ID. Proxima keeps source identifiers for lineage and uses a correlation ID to join events into the operational case.
Sometimes correlation is direct. Sometimes it requires a mapping table or an enrichment lookup. That step should happen before decision logic. Asking every rule or model to infer identity independently creates subtle duplication and missed joins.
Canonical fields are a contract, not a dumping ground
It is tempting to create one enormous schema containing every field seen in every source. That only moves the inconsistency into a larger object.
A useful canonical payload contains the facts required by the workflow. The shipment exception pack does not need the complete TMS data model. It needs the identifiers, times, exception context, customer priority, value, and other fields used to decide or explain the next step.
Fields should be named for their meaning, not their source column. Source-specific transforms belong in mapping. Business calculations belong in derived fields. The original row or message remains available as an artifact when deeper debugging is needed.
Missing data has several meanings
A missing value is not one thing. A field may be absent because the source does not provide it, because mapping failed, because it is not applicable, or because it has not arrived yet.
Those cases can lead to different decisions. A customs document that is known to be missing is not the same as a carrier feed that has not reported document status.
Proxima retains the reason alongside the normalized record where it can. A workflow can route an incomplete case for enrichment rather than treating missing information as a normal business value.
The design trade-off is between strictness and continuity. Rejecting every incomplete event protects decision quality but can stop the operation. Accepting everything keeps events moving but may produce false certainty. Proxima separates fatal contract failures from recoverable data gaps so the workflow can make that choice explicitly.
Decide which source wins
Two sources may report different values for the same fact. The latest arrival is not necessarily the most authoritative. A carrier may own movement status, while the order system owns the customer promise and the CRM owns account priority.
Authority therefore has to be defined by fact and workflow. When two equally authoritative sources disagree, the design rule is to preserve the conflict and route the case accordingly rather than silently selecting a convenient value.
This is a business design decision as much as a technical one. The platform can enforce the rule, but the workflow owner must decide which source the operation trusts.
Version the meaning
Source formats change. A system adds a status, a field changes units, or a workflow begins using a fact that was previously ignored.
Versioning tells the adapter which source interpretation applies and tells the decision engine which workflow meaning applies. Both versions belong in the trace.
Compatibility also needs an explicit policy. A new optional field may be backward compatible. Renaming a field or changing its units is not. The design rule is to reject or quarantine an event the runtime cannot interpret rather than silently producing a decision from malformed data.
Lineage is what makes debugging possible
When an operator questions a decision, the team needs to answer a short chain of questions:
- Which source records produced this event?
- How were the fields mapped?
- Which derived facts were calculated?
- Which workflow version evaluated them?
- Which action followed?
That chain starts in the event contract. Without source system, source record, timestamps, and mapping context, the rest of the decision trace rests on memory and log searches.
This is unglamorous engineering, but it is one of the main differences between a model that performs well on a clean example and a system that can work inside an operation. Before an agent can make a good decision, the platform has to establish what happened, when it happened, and which case it belongs to.