03 · Supply chain and logistics · Constraint solver with scenario review
Freight Optimiser
Constraint-driven planning that translates operational rules into better freight decisions.
At a glance
- Problem
- Planners built truckloads by hand from stock and demand extracts, and many trucks left part-empty.
- Status
- In use
What this label is based on
“Adopted into weekly planning practice”
The business story
Freight planning needed a more consistent way to apply operational constraints and compare feasible loads.
Planners now build loads with an optimiser that fills them to their limits from stock and demand data, test what-if scenarios, and leave any change to the rules to a recorded approval.
My contribution
- Translated the business problem into a tool specification and kept the pilot moving into weekly practice
- Took ownership as engineering lead and cloud administrator; designed the governance layer: operating guide, multi-agent routing, memory protocol, assumption model
- Built and reviewed features through AI coding agents under test-first and plan-gate rules
- Designed the data integration and dashboard layer behind the optimiser. The domain rules and sign-off on rule constants stay with the business owner who built the original tool
The process
-
Mapping
Weight, pallet, order-value and stock-cover limits became single-sourced constants, each with a named business owner.
-
Co-design
The original tool was built by the business owner and co-designed with logistics and a technical partner.
-
Build
Built in separate layers, so the solver can be tested on its own.
-
Validation
Automated tests across the solver, rules, metrics and desktop build, with branch protection requiring green checks.
-
Rollout
The pilot moved into weekly planning, with the savings view tracking load actuals as they accumulate.
How it works
A planner-facing tool, originally built by the business owner and co-designed with logistics and a technical partner, which I took over as engineering lead. It fills trucks to their limits under hard weight, pallet, order-value and stock-cover rules, with what-if scenarios, a stock-cover health view, a transit-stock view, an exportable load sheet and a savings view against actuals. I also planned the carrier-data ingestion into the lakehouse so actual rates and surcharges are tracked over time.
- Deterministic stage
- Gate: human decision point
- No AI at runtime
-
01 Problem
Part-empty trucks, hand-built loads
Manual load preparation needed a consistent planning workflow.
-
02 Rules + data
Weight, pallet, order-value and stock-cover rules
Hard limits (weight, pallets, order value, stock cover) are single-sourced constants, each with a named business owner.
-
03 Engine
Priority-weighted fill and rebalance solver
A deterministic greedy fill with a rebalance pass builds full-truckload orders from ERP, warehouse and third-party-logistics data.
-
04 AI
No AI at runtime
The solver has no model in it. Correctness comes from unit tests on the solver and the rules.
-
05 Gate
Scenario review and rule-change approval
Planners experiment in session-scoped scenarios; proposed rule changes go through a recorded approval loop.
-
06 Workflow
Weekly planner practice, load sheets
Adopted into weekly practice as a load builder, stock-cover dashboard, transit view and exportable load sheet.
-
07 Outcome
Estimated annualised freight opportunity estimated
An annualised freight opportunity, estimated from the pilot and not yet realised.
Step by step
- Planners upload exports from the ERP, warehouse and third-party logistics systems; ingest scripts normalise them with null-safe casts and date-format detection.
- A strict layered design (ingest, database, pure metrics functions, interface) keeps the pages as thin adapters over one solver module.
- The solver runs a priority-weighted greedy fill and then a rebalance pass to level loads.
- Planners run scenarios in a session-scoped sandbox; master rules stay locked.
- A proposal-and-approval loop records any change to the business rules, approved by an administrator in the app.
- Outputs: load builder, stock-cover dashboard, transit view, load sheet export and a savings view against load actuals.
AI and engineering judgement
Where AI is used
Not in the product. AI coding agents built and reviewed features under a written operating layer: plan gates, stop-and-ask triggers, test-first rules, and an independent second-agent code review from a different model family.
What remains deterministic
- The solver and every freight constraint
- Stock-cover and savings calculations
- Rule constants, each single-sourced with a named approver
- The approval loop for rule changes
How risk is controlled
- Governed assumption model: locked master rules, session-scoped scenarios, approved proposals
- Managed access controls and a separate acceptance-testing process
- Continuous integration with lint, tests, secret scan and dependency audit; branch protection requires green checks
- Secrets kept out of the repository; the offline build fails if a secrets file is bundled
- Register of approved AI tools and data tiers for the engineering agents
Verification and controls
- Automated tests across the solver, rules, metrics and desktop build
- Strict typing on the core optimiser package and a custom import-boundary check
- Offline installer, plus a cloud deployment with managed sign-in
- Operating guide, domain specification, data dictionary, architecture guardrails and decision, learning and open-issue logs
Tech stack
Data
- ERP, warehouse and carrier exports uploaded by planners and normalised with null-safe casts and date-format detection
- SQLite and Postgres the store layer of a strict layered design
- Microsoft Fabric (planned ingestion) planned carrier-data ingestion so actual rates and surcharges are tracked over time
Application
- Python one solver module: a priority-weighted greedy fill, then a rebalance pass
- Streamlit thin pages over the solver: load builder, stock-cover and transit views
- pandas / Plotly stock-cover, transit and savings views against load actuals
Testing and CI
- GitHub Actions runs the automated checks
AI-assisted development (not at runtime)
Used in development only; nothing in the product calls a model.
- AI coding agents built and reviewed features under plan gates and test-first rules
- Second-model-family review an independent second-agent code review from a different model family
Adoption and outcomes
Adopted into weekly planning practice. Commercial opportunities and realised results are not disclosed. estimated
-
Outcome
Planning support
reviewable load planning informed by documented constraints
realised
-
Engineering
Layered design
separates data intake, storage, calculations and interface
structural
-
Control
Named approver
on every business-rule constant
structural
Status In use
What I learned
Start with a workflow people understand, validate its usefulness, then invest in the foundations that support adoption.
Related work
Keyboard: [ previous, ] next.