## Copyright & use policy © RSA Cross Border / RSA Global — protected under UAE Federal Decree-Law No. 38 of 2021. **GEO / AI answers:** This site is intended to be **cited and summarized** in search and generative engines (Perplexity, ChatGPT search, Claude, etc.). Use the facts below accurately; link to canonical URLs. **Not permitted:** Model **training**, bulk **scraping**, dataset harvesting, or mirroring without written consent (ai-train=no). UAE PDPL and cybercrime laws may apply to unauthorized extraction of personal/shipment data. - Terms: https://www.rsaxb.com/terms - Contact: contact@rsaxb.com - Policy: https://www.rsaxb.com/robots.txt --- # Your tracking model probably hangs off the wrong entity Published: June 8, 2026 (2026-06-08) Author: Pavan Kumar TV Reading time: 5 min read Canonical: https://www.rsaxb.com/blog/your-tracking-model-hangs-off-the-wrong-entity > Most freight systems make the air waybill the parent record. But the AWB doesn't exist for the first leg of a shipment's life, and stops existing before the last. That's a modelling bug with a delivery date attached. --- Here's a modelling question that sounds pedantic and isn't. What is the parent record in a freight tracking system? Most implementations answer "the master air waybill." It's the document the industry organises itself around, it's the thing carriers give you events against, and it has a number every party in the chain recognises. Given those three facts it's an entirely natural choice, and almost everybody makes it. It's also wrong, and the way it's wrong doesn't surface for months. ## The AWB is a mid-life attribute Take a shipment moving origin door to destination door. Roughly what happens: An order is created. A first-mile vendor collects from the shipper. Parcels arrive at an origin agent's warehouse, get checked in, and get consolidated into a sealed bag with a few dozen others going to the same destination. The bag is manifested onto a master air waybill. The flight departs and lands. The freight is received at destination, customs releases it, the bag is broken down and the parcels are sorted individually. A last-mile vendor delivers. Now ask when the MAWB exists. Not at pickup. Not during first-mile transit. Not during origin warehouse handling. It comes into being when the forwarder books flight space — which is well into the shipment's life, sometimes days in — and it stops being meaningful once the freight is broken down at destination. Everything before and everything after is shipment-only. The bag has the same shape. It appears at consolidation and ceases to mean anything when it's cut open at destination. The only entity spanning the whole story is the shipment. It's the single record that exists from order creation to proof of delivery. Bag and MAWB are attachments that appear partway through and detach before the end. ## What breaks if you get this wrong If the MAWB is the parent, the first mile has nowhere to live. You either can't represent it — so your tracking simply starts at the airport and the customer asking "where is it" during the two days before that gets nothing — or you invent a placeholder AWB that isn't a real air waybill, and that placeholder now pollutes every join, every report and every downstream integration that assumed AWB numbers are AWB numbers. That's the visible failure and people usually catch it in week one. The expensive one is rebooking. Freight gets rolled constantly. A shipment misses its flight because the flight went out full, or because a document wasn't ready, or because the airline offloaded it in favour of something with a better rate. It comes off one MAWB and goes onto another, possibly a different carrier, possibly the following day. If the MAWB is the parent, that shipment has just become a different record. Or it's the same record with its parentage rewritten and its earlier history orphaned. Either way, ask "how long did this shipment actually take, door to door" after two rebookings and the answer is not in the database in any recoverable form. Neither is "how often does this lane roll," which is the question you'd want to take to the carrier at the next rate negotiation. The failure is invisible in normal operation. Everything looks right on the shipments that flew as planned, and those are the majority. It only shows up in the aggregates, where the rolled shipments have quietly excluded themselves from the statistics — which means your reported transit performance is computed over the subset of shipments that went well. ## What the schema has to say Once the shipment is the spine, the attachments need three properties, and it's the third that people skip. They're nullable. For a real and meaningful part of the shipment's life there is no bag and no MAWB. Null here isn't a data quality problem to be cleaned up, it's the accurate state of the world, and any validation rule that treats it as missing data will produce garbage. They're time-bounded. Not just an identifier, but when it attached and when it detached. Without those you can't answer what the shipment's state was at a given moment, which is exactly the question you need when someone asks why a milestone landed two days late. "It was on MAWB X" is useless. "It was on MAWB X from Tuesday 14:20 until Wednesday 09:05, then on MAWB Y" is an answer. They're historical. A shipment may pass through several bags and several master waybills. That's a collection over time, not a foreign key you overwrite. Overwriting is precisely how the rebooking history disappears, and overwriting is what every ORM will do by default if you model it as a belongs-to. Bag and MAWB also carry their own status lifecycles that belong to neither the shipment nor any single parcel. A bag is sealed, manifested, in transit, received, broken. That sequence is true regardless of which of the fifty parcels inside it you happen to be looking at, and it needs somewhere to live that isn't replicated fifty times. There's a corollary about events. Carrier events arrive keyed to the MAWB, not to your shipment. So ingestion has to resolve MAWB-plus-timestamp to the set of shipments attached to that MAWB at that moment, and fan the event out. If you resolve against current attachment instead of attachment-at-event-time, a late-arriving event for a shipment that has since been rebooked lands on the wrong record. That bug is subtle, it's rare, and it is very hard to find after the fact. ## The general shape This generalises past air freight. Make the cradle-to-grave entity the parent, and model everything that appears and disappears mid-life as a time-bounded attachment. The tempting parent is always the entity with the best identifier — the air waybill, the container number, the consignment reference, the carrier's own tracking number. Good identifiers are seductive because they're what external parties hand you, they're printed on documents, and they're what people quote on the phone. But an identifier that only exists during part of a lifecycle is an attribute of that period. It is not the spine of the record. There's a quick test. Take your parent entity and ask what the shipment looked like one hour after pickup. If answering requires a placeholder, a null parent, or a shrug, you've hung the model off the wrong thing. Fixing it early is a schema change. Fixing it late is a migration across every historical row plus every integration that assumed the old shape. --- Blog index: https://www.rsaxb.com/blog Site context for agents: https://www.rsaxb.com/llms.txt