Resolution Requests (R2s) are designed for uncertainty.
They work best when changes are infrequent, exceptions are novel, and each decision needs to be evaluated in context. In those cases, slowing the decision without stopping the work is exactly the right strategy.
But not every operation lives in that regime. When volume increases, certain “exceptions” stop being exceptional. Equipment breaks down. Capacity shifts. Carriers swap assets. The same patterns repeat, and resolving each one manually reintroduces the very judgment pressure RRs were meant to remove.
That’s the point where authorization must move from ad-hoc resolution to pre-authorized execution.
This article explains how that transition works, and how to use Admiral Execute when volume makes one-off R2s impractical.
The structural constraint R2s are not meant to solve
R2s exist because authorization often needs to travel across company boundaries without leaking context. They provide a safe way to handle uncertainty when participants change or information is incomplete.
But R2s are intentionally conservative. Each request, pauses a binding decision, routes it to an authority, and waits for confirmation. That’s the right behavior when the scenario is rare, the risk is ambiguous, or the cost of delay is low.
It becomes the wrong behavior when the same situation happens dozens of times per week, the decision criteria are already known, and speed matters more than deliberation. At that point, resolving each case individually isn’t safer, it’s slower.
The how-to question: when do you move to Execute?
The practical rule is simple: If you can describe the condition under which a change is acceptable before it happens, you should pre-authorize it. That’s what Execute is for.
Execute doesn’t replace R2s. It absorbs repetitive, predictable authorization paths so they don’t need to be re-decided each time.
A concrete example: pre-authorized carrier swap
Let’s walk through a scenario where R2s no longer scale.
The situation:
- A shipper tenders a high-volume lane to Carrier A.
- The contract allows carrier swaps under defined conditions (breakdown, equipment unavailability).
- Carrier A frequently relies on Carrier B for contingency capacity.
This is not an exception. It’s expected behavior. Resolving every swap through RRs would slow execution, flood approvers, and eventually push decisions back to the frontline. The dock or gate shouldn’t judge “this is probably just a normal swap”. Instead, the swap is pre-authorized in Execute.
Step-by-step: how Execute handles the swap
1. The policy is encoded upstream
Before execution begins, the shipper and Carrier A agree to a policy:
- Carrier A may transfer custody to Carrier B under specific conditions.
- Carrier B equipment must meet defined criteria.
- All swaps must be visible in execution systems.
That policy lives in Execute. Not in inboxes, not in side agreements.
2. The breakdown occurs
Carrier A experiences an equipment issue mid-lane.
Instead of calling the shipper, sending emails, creating an R2, or asking the gate to “just let it through”, Carrier A dispatch assigns the load to Carrier B’s equipment inside Execute.
3. Custody transfers are recorded automatically
Carrier B accepts custody through the platform. At this point the execution record updates, the authorized equipment changes, and the swap is explicitly marked as such.
No human judgment is required to interpret what happened. The system knows.
4. The driver arrives at the gate
Carrier B’s driver shows up. The livery is different. The tractor number doesn’t match the original plan. The driver wasn’t part of the original tender. In a traditional workflow, this is a judgment moment.
In Execute, it isn’t.
5. What the gate sees
At the gate, the operator sees this load has an authorized carrier swap. This equipment is the currently authorized asset. This driver is associated with that equipment. The swap occurred under pre-approved conditions.
No phone calls. No paperwork inspection. No “does this feel right?” decision. Execution proceeds because authorization already exists.
Why no R2 is required here
Nothing about this situation is ambiguous. The conditions were known. The policy was agreed to. The authorization was pre-granted. Creating an RR at this point would not increase safety — it would reintroduce delay and pressure without adding information.
This is the key distinction:
- RRs resolve uncertainty.
- Execute scales.
How this prevents judgment from creeping back in
The most dangerous moment in freight execution is when something looks slightly different and someone has to decide whether to allow it anyway.
Execute removes that moment by ensuring that, authorized changes are visible, unauthorized ones are blocked, and frontline teams are never asked to infer intent. They don’t decide whether a swap is legit. They see that it already is.
How this fits with the rest of the system
Resolution Requests still matter. They handle new scenarios, edge cases, first-time decisions, and genuine uncertainty. Execute takes over when those decisions become patterns.
Together, they form a ladder:
- Resolve uncertainty once.
- Encode the result – this is why recording a decision is important.
- Execute it repeatedly without friction.
Stay Connected
Want more insights like this? Follow Level5Fleet for future articles, freight industry trends, and updates on building a smarter, more secure supply chain:
🔗 LinkedIn
🐦 X: @Level5fleet
📘 Facebook
📸 Instagram
