Pallet’s Plan to Never Solve the Same Freight Exception Twice

The rule book was a recipe-card holder

At Eassons Transport in Nova Scotia, an account manager had built a physical recipe-card holder. One card per customer. Temperature settings. Weight conversions. Delivery schedules. The little instructions that make a shipment work, gathered somewhere a colleague could find them. Pallet describes the holder in its Eassons case study.

There is something wonderfully practical about that object. It has no login screen. It needs no integration. It also reveals a problem that a new piece of software can easily miss: the shipment record and the knowledge needed to create it live in different places.

A computer can have every required field filled in and still misunderstand the job. A person can look at a sparse request and know exactly what the customer means. The distance between those two abilities is where freight exceptions accumulate.

The question behind Pallet’s continuous intelligence approach is what happens after somebody closes that distance. Does the answer disappear into the completed ticket? Or does the next shipment inherit it?

An exception gets a second job

An exception begins as work waiting for a person. In Pallet’s proposed feedback loop, it should finish as a reusable answer: a human resolves a novel case, Pallet validates the intervention, and the resulting memory becomes available when a matching case arrives.

Pallet’s agent platform page makes the underlying promise explicit: human interventions are committed to an Enterprise Memory layer. The important word is “matching.” An answer has to belong to a situation. Otherwise, a useful correction can become a confidently repeated mistake.

Consider a hypothetical account whose delivery instructions distinguish between two receiving locations on the same property. An operator clears up which location a particular order needs. Saving only the address loses the lesson. Saving the account, facility, order context and reason for the decision gives the next case something useful to consult.

That example is an illustration, not a reported customer incident. It shows why the loop needs validation between a human’s action and the agent’s next action. A one-off accommodation might close today’s ticket without establishing tomorrow’s default. The system has to preserve that distinction.

The intervention now has two jobs. It gets the current shipment moving. If it is suitable for reuse, it also reduces the work waiting in the next queue.

Why another rule is not enough

A static automation rule can be very good at its assigned task. Given a known trigger and a defined instruction, it executes the instruction. An operator’s correction does not, by itself, change that rule. Somebody must translate the lesson into logic, update the workflow and check the result.

A system organized around reusable operational memory puts that translation closer to daily work. Pallet’s technical explanation describes memories written in plain English and organized by topic, customer and location. Its reasoning process retrieves relevant instructions, checks a proposed result and escalates unfamiliar scenarios.

The operational difference is easy to see in a hypothetical request that changes format. Yesterday’s instruction was buried in a PDF. Today’s arrives in an email attachment. Tomorrow’s references a different facility. A rule tied narrowly to yesterday’s document layout may need another branch. A contextual memory can remain relevant across those surfaces, provided the underlying situation still matches.

That does not make rules obsolete. Rules remain useful for firm limits and predictable steps. Memory addresses the surrounding interpretation: what this account expects, which lane matters, which facility is involved, and how this document expresses the request.

Compounding starts when those distinctions survive the ticket. The next operator, shift or agent can use an answer that previously required finding the one person who remembered it.

The two percent that still needs a person

Eassons gives the idea a concrete boundary. Pallet reports 98% touchless load processing, with new edge cases escalated to human operators. The remaining 2% is therefore work requiring attention, not a license to guess. The agent reads tenders, enriches shipment information and creates loads in TruckMate. Source: Eassons.

That boundary changes how the leftover queue should be understood. A novel case can be both an interruption and a chance to improve the next decision. Closing it quickly matters. Capturing why it was closed matters too.

Imagine two queues of equal size. In the first, experienced people repeatedly answer an already settled question. In the second, people handle unfamiliar requests because earlier answers are available for reuse. The count looks identical. The quality of the work is different.

A useful measure would therefore track which exceptions recur after validation, alongside how often humans intervene. A falling review count means little if avoidable errors are rising. A smaller queue of genuinely new cases would tell a more convincing story: yesterday’s work has made today’s routine work easier.

When two item records both look right

At Lineage, the difficulty sharpens. Customer product descriptions may differ from the records in a warehouse management system, and customer names can correspond to multiple entity IDs. Pallet says its order management agent resolves line items against facility catalogs using captured operator knowledge. The case study reports near-100% accuracy for unambiguous orders and 95% for ambiguous resolution. Those are different populations, not interchangeable scores. Source: Lineage.

In a hypothetical catalog, two entries might both resemble the words in an email. Picking the closest phrase could be the wrong move. The right decision might depend on which customer entity placed the order, which facility holds the stock or which lot the attachment specifies.

This is where operator-grade judgment becomes more than a flattering description. It means using the details that separate a plausible answer from the right operational answer. A remembered mapping can help only within the circumstances that made it correct.

If those circumstances change, the old answer deserves another look. A renamed item, a revised account instruction or a new facility can turn yesterday’s useful memory into today’s bad shortcut. Continuity requires remembering the conditions as carefully as the conclusion.

The knowledge factory runs during the shift

Pallet says it generates thousands of new memories per day across customers. The significance is the cadence: lessons produced as operations happen, rather than held until a periodic model-retraining project. The count is a company claim, not a measured outcome from either customer example.

Memory creation and model retraining describe different changes. Retraining changes a model’s learned parameters. Adding a usable operational memory gives a system more context to retrieve. A team can settle an account instruction without waiting for a new foundation model to be released.

Think of the work as a production line with a demanding inspection station. The raw material is a resolved exception. The output is knowledge fit for reuse. Volume matters only if the output is correct, specific enough to retrieve, and current enough to trust.

“Across customers” also needs a careful reading. A platform-wide activity total does not mean that one customer’s private instructions become another customer’s knowledge. Pallet’s product page says customer data stays theirs and is never shared.

The useful promise is that an operation can accumulate its own answers during the working day. The daily count tells us the proposed process has throughput. It does not tell us how many future exceptions each memory will prevent.

An answer is not a permission slip

There is a trap in the phrase “never resolve an exception twice.” Taken literally, it could encourage an agent to force every unfamiliar case into a familiar category. That would defeat the purpose of capturing judgment in the first place.

The control boundary should stay clear: new or high-risk exceptions remain subject to human review. A validated answer can reduce repeat escalation within an approved workflow. It should not silently authorize a different action, a larger commitment or a new class of decision.

This is an operational requirement for the loop described here, not a claim that the public pages document every approval setting. Those pages explain memory, checking and escalation; they do not specify a complete permission policy for every deployment.

Knowledge answers “What have we learned about this situation?” Authority answers “What may the agent do?” A useful system needs both answers before it acts. A facility preference may help prepare a correct order while a separate approval requirement still governs release.

Return to the recipe-card holder. Its achievement was to preserve a practical answer where somebody else could use it. Continuous intelligence extends that ambition into the workflow: resolve the unfamiliar case, validate the lesson, retrieve it when appropriate, and keep asking for help when the situation demands it.

The next shipment arrives. The operator should have fewer old questions to answer—and more time for the question nobody has seen before.