
Logistics Decision Logic
Every routing decision, explainable. Every exception, handled by rule.
Your routing logic lives in a dozen systems
A shipment needs to move. Which carrier? Which route? Which mode? The answer depends on rate agreements, capacity constraints, service levels, customs requirements, partner preferences, and a dozen other factors. The logic that decides lives scattered across TMS configurations, spreadsheets, tribal knowledge, and emergency Slack threads.
Fragmented rules. Rate tables in the TMS. Carrier preferences in spreadsheets. Customs requirements in someone's head. Partner constraints in email threads. When a decision is made, good luck reconstructing why.
Exception avalanche. Weather delays, capacity crunches, customs holds, damaged goods, missed pickups. Every disruption triggers manual intervention. The "exception" becomes the norm.
Unexplainable decisions. Auditor asks why this carrier was selected. Customer asks why the shipment was delayed. Partner asks why their lane was bypassed. You spend hours reconstructing a decision made in seconds.
Agent opacity. Worse still, when optimization agents make routing decisions, even your own team can't explain why. The agent chose, but nobody knows the reasoning.
Change paralysis. New carrier onboards. Rate agreement updates. Compliance policy shifts. Each change means TMS reconfiguration, testing cycles, and hoping nothing breaks.
The decision was made. Nobody knows why.
What if every routing decision was a rule you could read?
Inferal makes logistics decisions visible. Carrier selection, route optimization, exception handling: rules you can read, version, and change without deployment cycles.
Whether a human or an agent makes the routing call, the rule is the same. Decisions become explainable regardless of who decides.
- Shipment exceeds carrier's weight limit for this lane → automatically route to qualified alternative
- Partner requests expedited handling and margin threshold is met → upgrade to air freight
- Customs documentation incomplete and departure is within 48 hours → hold shipment and alert operations
- Preferred carrier at capacity and SLA at risk → trigger backup carrier cascade
Rules evaluate against shipment data, carrier status, partner constraints, and real-time conditions. When patterns match, routing decisions execute with full context captured. The decision and its rationale exist as a single record.
The rule is the decision. The decision is the record.
From firefighting to standing orders
Exception management shouldn't mean humans frantically rerouting shipments. It should mean rules that already know what to do when things go wrong.
Exceptions become conditions. "Carrier delay exceeds 4 hours" isn't an emergency. It's a condition that triggers the next rule: reroute, notify customer, update ETA.
Cascading responses. Primary carrier unavailable triggers secondary. Secondary at capacity triggers spot market query. Each step is a rule, not a phone call.
Context preserved. When the exception fires, the response knows the full shipment context: origin, destination, contents, constraints, customer requirements. No re-gathering information.
Patterns emerge. Rules that fire repeatedly reveal systemic issues. That carrier's Tuesday delays aren't random. That customs form keeps failing for the same reason.
Exceptions aren't surprises. They're conditions you haven't written rules for yet.
Decisions that explain themselves
When the auditor asks, when the customer complains, when the partner disputes: you shouldn't be reconstructing. The answer should already exist.
Audit response. "Why was Carrier B selected over Carrier A?" The record shows: Carrier A was at capacity for westbound lanes, Carrier B had lower rate for this weight class, and customer allowed 48-hour flex on delivery. Three conditions, one decision, fully traceable.
Customer inquiry. "Why was my shipment delayed?" The record shows: severe weather in origin region triggered the hold protocol. Rerouting was evaluated but would have exceeded SLA worse than waiting. Notification sent at 14:32.
Partner negotiation. "We should be getting more volume." Here's the data: your lanes matched 847 shipments, but 312 were disqualified due to capacity constraints you reported. The rules are visible. Let's update those constraints together.
Transparency isn't a feature. It's the default output of rule-based decisions.
Every decision comes with its own explanation.
Constraints that update themselves
Carrier capacities shift. Partner preferences change. New routes open. Old ones close. Your logic should adapt.
Live constraints. Carrier capacity isn't a static number in a spreadsheet. It's a feed. When capacity changes, rules automatically reflect it.
Partner-managed rules. Partners update their own constraints: lanes they serve, capacities they have, rates they offer. Your rules reference their declarations.
Learned patterns. Seasonal demand, recurring exceptions, carrier reliability: patterns that emerge from data become suggestions for new rules.
When agents route, rules govern
Optimization agents can propose routes. Constraint agents can block violations. Monitoring agents can flag anomalies. Each operates within declared rules.
Whether the disqualification was made by your ops team or your optimization agent, the rules are visible. Each decision, traceable to the rule that enabled it.
Agents don't replace human judgment. They extend it, operating within boundaries you define and can inspect.