A Modern TMS Stores Results, Not Decisions: Why the Decision Layer is the Part That Matters

The record says what happened and not why

Six weeks after the fact, a finance lead asks a reasonable question. A full truckload moved on a lane with committed contract volume, and it went to a spot carrier at roughly 2.3 times the contract rate. Why.

The TMS answers thoroughly and uselessly. It can produce the order, the timestamp of the tender, the carrier that accepted, the rate paid, the delivery confirmation, and the invoice. Every record is accurate and complete.

What it cannot produce is the reason. Which carriers were evaluated. What the contract carrier’s available capacity was at that moment. Which constraints were binding, and whether one of them was a cut-off time that has since been changed. Whether the allocation rule in force that day is the rule in force now. Whether a human overrode the system, and if so, on what basis.

None of that is missing because someone forgot to log it. It is missing because the system has nowhere to put it. A TMS has tables for orders, shipments, stops, vehicles, carriers, rates, and invoices. It does not have a table for decisions. So the decision that sent that load to a spot carrier was never an object in the system. Only its residue was.

This is the gap the phrase “decision layer” points at, and it is more consequential than it sounds, because a surprising number of capabilities enterprises want from a modern TMS turn out to depend on it.

Also Read: Logistics Automation vs. Logistics Orchestration in 2026: What’s the Difference, and Why It Matters

What a decision layer actually is

A decision layer is the part of a platform that treats a decision as a first-class, persisted entity rather than as a transient step between an input and a record update.

Concretely, each decision object carries the inputs it was made from and their freshness, the options that were available, the constraints that applied and which of them bound, the version of the logic or model that produced the choice, the actor responsible whether software agent or human, and the action that followed.

Three things are commonly mistaken for this and are not it.

A rules engine holds logic, not decisions. It can tell you what the rule says today. It cannot tell you what happened when the rule met a specific load last March, or what the rule said at the time.

A data warehouse holds outcomes. It is excellent at what was delivered, when, and at what cost, and it has no representation of the alternatives that were rejected. Analysis built on outcomes alone can identify that cost per load rose without being able to identify which choices raised it.

An event log holds what happened in sequence. That is closer, and it still records state transitions rather than reasoning. “Tender sent” is an event. “Tender sent to this carrier because the contracted carrier had no compliant vehicle inside the cut-off window, at a cost premium of X, under allocation policy version 7” is a decision.

The distinction that matters commercially is between a system that decides and a system that records what was decided somewhere else, usually by a person under time pressure whose reasoning left the building with them.

Six things you cannot do without a decision layer

Audit. An audit of outcomes tells you what the operation did. An audit of decisions tells you whether it was reasonable at the time, which is the only fair standard. Without decision records, every post-mortem becomes an argument from memory, and the person with the best recall wins rather than the person who is right.

Replay. Testing a change to allocation logic requires running the proposed logic against real historical situations. That is only possible if the situations were stored, including the options and constraints in force. Where they were not, every logic change ships into production untested and its effect is discovered in the following month’s numbers, confounded with everything else that changed.

Attribute. When an outcome is wrong, three things could be at fault: the input was stale or incorrect, the logic was wrong, or a human overrode correctly-functioning logic. These have completely different fixes. Without a decision record capturing input freshness, logic version, and actor, teams cannot separate them and default to blaming whichever is least able to argue back, which is usually the software.

Version. “We changed the allocation policy in March” should be a verifiable statement tied to specific decisions. Without versioned decision records it is organizational folklore, and any metric that moved in Q2 cannot be connected to the logic change that may have caused it.

Bound autonomy. Autonomy levels configured per decision class are the accepted way to introduce automated decisioning safely. That requires a decision class to exist as an entity you can attach a level to. Where decisions are not modelled, autonomy collapses into a global switch, which is why so many deployments sit permanently at the cautious setting: there is no way to grant more authority to the safe decisions without granting it to the dangerous ones.

Learn. This is the one that does the most damage. Learning from operational history means pairing what was decided with what resulted, then adjusting. If the system persisted outcomes and discarded decisions, there is nothing to pair. The common diagnosis when a platform fails to improve over two years is that the models are weak. Frequently the models are fine and the training pairs were never retained.

Also Read: Agentic-Washing: How to Tell a Real Agentic TMS From a Rebranded Rules Engine in 2026

Why this shows up as five unrelated problems

The reason this rarely gets fixed is that nobody experiences it as one problem.

An operations lead experiences it as post-mortems that go nowhere. A technology lead experiences it as being unable to test a configuration change safely. Finance experiences it as disputes that cannot be settled from the record. A transformation lead experiences it as autonomy stuck at the level it launched with. A data team experiences it as a model that will not improve.

Five people, five backlog items, five different owners, none of them describing an architecture gap. Each item gets addressed locally: more logging here, a report there, a spreadsheet to track policy changes. None of the local fixes work, because they add more records of outcomes to a system that already has plenty and still has no decisions in it.

This is worth naming during procurement, because it is the pattern that distinguishes a platform that will keep getting better from one that will perform on day one exactly as well as it performs in year three.

Also Read: Why Governance Matters More Than Autonomy in Enterprise Logistics AI

Three architectures compared

The row that determines the rest is the first. Everything else follows from whether a decision was ever written down as a thing with properties. This is why it is an architectural question rather than a reporting one: you cannot add auditability, replay, or learning to a platform later if the events that would have populated them were never captured.

Also Read: Logistics AI Governance EU 2026: Six Architectural Mechanisms

What to ask a vendor

Five questions that separate a decision layer from a well-instrumented records system, and none of them can be answered with a dashboard screenshot.

Show me one decision record. Not a shipment record and not an audit log line. One decision, with its inputs and their timestamps, the options that were available, the constraints that bound, the logic version, and the actor. If this cannot be produced for a single load, the layer does not exist.

Replay last Tuesday with one constraint changed. Ask what it would take. If the answer involves reconstructing the day from outcome data, replay is not supported.

When a metric moves, can you tie it to a logic version. The test of whether policy changes are versioned in a way that connects to results.

What entity does an autonomy level attach to. If the answer is the platform or the user role rather than a decision class, autonomy cannot be graduated.

What does the learning step consume. Ask specifically whether it consumes decisions paired with outcomes, or outcomes alone. Outcomes alone gives you trend detection, which is useful and is not learning.

Also Read: What Is an Agentic TMS? A Practical Guide for Enterprise Logistics Leaders in 2026

How Locus builds the decision layer: DiSCO

Locus, the world’s first Decision-Intelligent, Agentic TMS, is built around DiSCO, its Digital Supply Chain Officer framework. DiSCO is the decision layer described above, expressed as eight specialized agents that coordinate across the transportation lifecycle: Capacity, Carrier, Dispatch, Hub, Customer, and Settlement agents, an Orchestrator that coordinates them, and the Mycroft AI Co-Pilot.

The organizing cycle is Sense, Decide, Execute, Learn, and the sequence is the argument. Sense establishes the inputs and their state. Decide produces a choice against more than 250 real-world constraints, and produces it as a retained artifact rather than as a transient step. Execute carries it out. Learn consumes the pairing of that decision with what actually happened.

That fourth stage is only possible because the second one persists. A platform that senses, decides, and executes without retaining the decision can still run a Learn step, and it will be learning from outcomes alone, which is the weak form. The reason DiSCO’s loop closes is that the decision exists as an object to close it around.

The same structure explains the six governance mechanisms, which are frequently read as a feature list and are better understood as consequences. Explainability is possible because a decision carries the constraints it honored and the alternative it chose against. Traceability is possible because the decision and its inputs persist. Evaluation is possible because decisions can be scored against outcomes. Autonomy levels are configurable per decision class because decision classes exist as entities. The execution sandbox can test a change because historical situations were retained and can be replayed. And human-in-the-loop escalation works because an override is captured as an actor on a decision rather than as an unexplained change to a record.

None of those six can be added to a platform that discarded its decisions. That is the practical reason the decision layer is the critical part of a modern TMS rather than one component among many: it is the layer the governable, testable, improvable properties are built on.

Locus has processed more than 1.5 billion deliveries for 360-plus enterprise customers across 30-plus countries, orchestrating over 1,000 carriers at 99.99% uptime, with more than $320 million in aggregate logistics cost savings. Locus is recognized by Gartner for seven consecutive years, featured in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, named a Leader in TMS by QKS Group (SPARK Matrix), and ranked #1 in Route Planning on G2’s 2026 Best Software Awards. In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently. Further analyst recognition is published in full.

Two deployments show decision records doing work in different agent domains.

A Fortune 50 parcel and logistics provider centralized dispatch across 51 sites in a 120-country network, running more than a million freight shipments a year against a 4,500-strong driver pool split between captive and third-party capacity. Weekly execution rate rose from 75% to 92% at 99.99% uptime. The finding that matters here is the more than $14 million in contracted capacity that local dispatch practice had never used, including $565,000 at a single site. That number is only discoverable if allocation decisions are recorded and comparable across sites. Fifty-one sites making undocumented choices produce fifty-one local habits and no way to see the pattern.

A paint industry leader automated freight reconciliation across 160 depots and more than 1,500 carrier invoices a month using the Settlement, Carrier, and Orchestrator agents. Checking each claim against contracted terms caught 5% to 6% variance that manual review had been missing, and cut payment cycles from 30 to 45 days down to 7 to 10. Reconciliation is a decision problem rather than a data problem: it requires knowing what was agreed, what was decided, and what was charged, and holding all three against each other.

Request a Locus decision layer assessment to review what your current platform retains at the point of decision, and which of the six capabilities above are available to you today.

Ask for one decision, not one dashboard

The fastest way to find out what layer you actually own takes one request and no project.

Pick a load from last month that cost more than it should have. Ask your platform team to produce the decision that sent it where it went: the inputs and their freshness, the options available, the constraints that bound, the logic version in force, and whether a person intervened.

If what comes back is a sequence of status changes and an invoice, you have a records system with good instrumentation. That is not a criticism of the software, and it does tell you why the post-mortems go nowhere, why configuration changes feel risky, and why the platform performs the same this year as last.