Context

Carrier tracking feeds arrive late, out of order, or missing entirely — yet customers still expect one clean, trustworthy timeline in the app. In logistics, that gap quickly becomes a trust problem because timeline accuracy sits at the center of day-to-day operations.

This project focused on milestone backfill and timeline correctness in a private air-tracking system. The goal was not to pretend third-party data was perfect. It was to make the system behave deterministically when the data was incomplete or ambiguous.

Problem

We were seeing timeline states that were technically derived but operationally confusing:

  1. Future-only position streams still showing a current map position.
  2. Milestone status/date combinations implying completion where completion was never explicitly confirmed.
  3. UI emphasis logic adding noise instead of clarity.

None looked dramatic in isolation. Together they made the product feel less trustworthy — even when the underlying events were being ingested correctly.

Constraints

Several hard constraints shaped the implementation:

  • We could not control provider payload quality.
  • Timeline logic had to remain fully deterministic and auditable.
  • Fixes had to work across carriers without overfitting any one provider’s quirks.
  • UI and API behavior had to stay perfectly aligned.

The key product constraint was clear: “just drop odd events” was not acceptable. We still needed to preserve every useful signal while handling ambiguity safely.

What I Changed

I focused on three targeted behavior changes that made the entire timeline more trustworthy.

First, I updated current-position handling so the system now returns null when all known points are future-dated. Previously, showing the earliest future point as “current” created false precision and made the map look more certain than the data deserved.

Second, I tightened milestone status and date semantics so actual_date only appears when the status truly supports completion. This eliminated misleading “done” signals based on weak or incomplete events.

Third, I simplified the timeline UI by removing redundant milestone logic and visual emphasis that was exaggerating weak signals. Cleaner presentation made the underlying state easier to trust.

The guiding principle across all three changes was the same: unknown is often better than invented certainty. I updated tests alongside the logic so the new behavior stayed explicit and stable.

Validation

Validation targeted the exact edge cases that had been producing confusing output:

  • Shipments with only future-dated position points
  • Milestones with partial or ambiguous status fields
  • Sparse event histories where inferred order was weak

I added unit and feature tests to enforce null current-position behavior and stricter completion rules. I also manually reviewed representative payloads with ops stakeholders to confirm the output matched real-world expectations.

Ops teams immediately noticed fewer “why does this shipment look completed when the carrier hasn’t confirmed it?” questions. The directional result was cleaner timeline interpretation and visibly higher trust in edge cases.

Outcome

This work improved timeline trust — which matters as much as raw event ingestion in any visibility product.

  • Map and timeline states became less misleading in imperfect data scenarios
  • Milestone outputs became more internally consistent
  • Operators could rely on timeline cues even when provider data was incomplete

I’m keeping the outcome language directional because I don’t yet have a clean before-and-after escalation count isolated to this exact logic slice.

Tradeoffs and Lessons

This project reinforced three lessons I now apply to every tracking or visibility system:

Unknown is often better than invented certainty. Returning null for future-only position streams is a trust-preserving choice.

Milestone semantics must be strict. If completion indicators are loose, users quickly start doubting the entire timeline.

UI clarity is part of data correctness. The best backend logic can still be undermined by presentation choices that exaggerate weak signals.

The main tradeoff is that stricter logic can feel conservative (fewer events qualify as “completed”). In visibility products, that is the correct failure mode — far better than presenting inaccurate certainty.

What I’d Improve Next

If I extended this work further, I would move the timeline system from “stable and trustworthy” to “measurable and self-defending” by adding:

  1. Event-confidence metadata in API responses
  2. Timeline reason codes for every inferred or backfilled milestone
  3. Escalation tagging so correctness improvements can be measured directly
  4. Provider-specific anomaly dashboards to catch schema drift early

These additions would give the team proactive visibility, easier governance, and a system that stays trustworthy as carriers evolve.

If your tracking timelines are brittle because provider data is messy, I can design backfill and normalization logic that users actually trust.