Case Study · FedEx · 2024–Present
Architecting FedEx Network 2.0's pickup-and-delivery package cost model
The problem
Network 2.0 merges FedEx's Express and Ground pickup-and-delivery operations across the U.S. and Canada — a consolidation FedEx has discussed publicly. The cost systems underneath were never built for that. Two networks meant two sets of cost logic, each written against assumptions the other didn't share, and neither able to cost a package moving through the merged operation.
The wider program is a full shipment-lifecycle cost model intended to replace those legacy systems end to end. Pickup and delivery was sequenced first on strategic importance — which meant building it before most of the surrounding domains existed, while making sure it would still mesh with them when they arrived.
That sequencing is the part outsiders tend to miss. Building first is not the easy slot. There is no reference implementation to copy, no settled conventions to inherit, and every structural decision becomes a precedent something else will have to live with.
What I built
- An activity-based, package-level cost model for the merged pickup-and-delivery network — built from scratch, costing every package the network moves, and structured to interoperate with the program's remaining cost domains as they come online.
- The costing methodology, core logic, and business requirements, authored end to end and refined through discovery sessions with the customer and stakeholder groups whose operations the logic had to describe.
- The model's machine-learning suite — clustering and regression approaches — which I conceived and specified; data scientists built to specification and carried it through feature engineering.
- On the component carrying the most uncertainty, I wrote the prototype myself in Python to prove the approach was viable before committing a team to it.
- A custom agentic-AI workflow in Databricks, with self-authored skill and context files, that cut analytical and query build time from days to hours. Peer analysts have since adopted it.
High-abstraction view by design — the deeper specifics stay with FedEx. Domains beyond pickup and delivery are shown unnamed deliberately.
What changed
The program needed funding before it could become real. I led the authoring of the business case and presented it at corporate stage-gate myself — arguing for the full lifecycle rebuild, not just the pickup-and-delivery piece. It was approved, and the approval funded a dedicated data-engineering and data-science build team.
What exists now is a working model unifying cost logic that two separate legacy networks used to carry independently. It is in validation, not yet the system of record — the honest status, and the right one for something this consequential. Validation itself is where the agentic tooling earns its place: each build-and-validate cycle that used to take days now takes hours, which is the difference between checking an assumption and living with it.
Several models are now in flight across the program, with business teams carving out requirements against the methodology the funding case established. The deeper specifics stay with FedEx, as they should.
Why it matters
Cost models are opinions about how work happens, written precisely enough to compute. Get the logic wrong and you get confident numbers describing an operation that doesn't exist — which is worse than no model at all, because people act on it.
That is why the interesting work here isn't the machine learning. It's the discovery sessions, the requirements written against real operational behavior, and the decision to prototype the riskiest component personally before asking anyone to build it. The AI tooling matters because it compresses the loop between having a question and having an answer you trust. At this scale, that loop is the constraint.