Logistics rules with traceability, validation, and room to change

01 / Context

A rules-heavy logistics domain

Logistics restrictions depend on several dimensions of a shipment and its route. The work needed to support those decisions across services while keeping the behavior understandable and safe to evolve.

02 / Problem

Complexity was both a correctness and a latency problem

Restriction decisions combined weight, dimensions, domains, and route rules. That made change management, diagnosis, and response performance connected concerns: a rule system that is difficult to trace is also difficult to validate before and after a rollout.

03 / Approach

Build explicit decision paths and reusable service boundaries

• Built Go and Python services and shared backend toolkits for logistics restrictions used across multiple services and teams.
• Designed a versioned, traceable Go decision engine for weight, dimensions, domains, and route rules.
• Built a third-party API → Go → BigQuery pipeline for historical logistics analysis.
• Trained and deployed a production ML classifier for air-transport eligibility, with monitoring based on recall, accuracy, and precision.

04 / Validation & rollout

Treat rollout safety as part of the system

The decision engine was validated through shadow tests and metric comparison before relying on the new behavior. Rule changes also used safer rollout controls. The classifier was monitored with recall, accuracy, and precision so model behavior remained visible after deployment.

06 / Lessons & trade-offs

Make correctness inspectable before optimizing the path

In a rules-heavy system, traceability is a performance enabler as much as a correctness property: it gives engineers a way to compare behavior, isolate expensive paths, and roll out changes with evidence. The trade-off is deliberate structure around versioning, validation, and monitoring instead of an opaque shortcut that is faster to change once but harder to trust.