Ripple Takes Pentagon's Jebel Ali Customs to AI After Cutting UK Prep 1,400 Hours a Week

The Analysis

On 20 October 2026 the AI platform Ripple announced that Pentagon Freight Services, a UK freight forwarder, had selected it to run customs and warehouse operations in the United Arab Emirates. The scope deserves a slow read because it is wider than the headline. Inside Jebel Ali Free Zone the system is being pointed at customs documentation, export documentation, oil country tubular goods inventory, warehousing billing and operational reporting, across both warehouses and yards. It pulls and cross-checks data from three source documents: the commercial invoice, the packing list and the Bill of Entry. For every piece of cargo it keeps one auditable record carrying four things, the specification, the yard location, the HS code and what was actually declared.

The numbers Pentagon is willing to attach its name to all come from its UK operation, not from the UAE. Up to 1,400 hours a week of manual document preparation removed. Clearance cost down 60%. Software cost down 40%.

Every time a press release hands me a number this clean, my instinct is not to argue with the number. It is to find the queue behind it. Think of it as a queue, because that is exactly what a documentation desk is: cargo arrives, documents are the workload on the servers, and the thing that actually costs money is the waiting.

Here is the model I want on the table before anybody puts 1,400 hours into a budget. A customs documentation desk is a queueing system with a feedback loop bolted on. Arrivals are declaration events. Service time is the minutes a clerk spends per file. And the parameter nobody ever measures, because it is invisible on a timesheet, is the rework rate: the share of files that come back because the invoice, the packing list and the Bill of Entry do not agree. Rework is a feedback arc, and a feedback arc multiplies your arrival rate. If a quarter of your files bounce once, your effective arrival rate is not the raw arrival rate, it is the raw rate divided by one minus the rework rate, which is 1.33 times as much. That is the variable. Not the typing.

Start with the bottleneck question, because it is the only question that decides whether this project is worth anything at all. A documentation desk has three parameters you can move: how many files arrive, how long each one takes, and how many of them come back. Most automation business cases are built entirely on the second one, because the second one is the only one that shows up on a timesheet. One thousand four hundred hours a week is a timesheet number. It is a service-time number.

Here is why that matters. In any single-server queue, the time a file spends in the system is roughly the service time divided by one minus utilisation, where utilisation is the arrival rate times the service time over available capacity. Written down it is boring. In practice it is a cliff. At 80% utilisation the average file waits about five service-times. At 90% it waits about ten. Same desk, same people, 12.5% more load, and the waiting time doubles. Nothing else changed.

Two consequences fall out of that, pointing in opposite directions. The encouraging one: on a desk really running at high utilisation, cutting service time is enormously powerful, because you attack the numerator and the denominator at once. A 40% cut in handling time at 85% utilisation does not shave 40% off the queue, it collapses it. So the 1,400-hour claim is not inherently silly. On a saturated desk, removed hours buy back a great deal of lead time.

The discouraging one: the same convexity means the benefit you can actually bank is extremely sensitive to the utilisation you run at, and almost nobody measures their own. A saving quoted with no utilisation figure attached to it is not a forecast, it is a hope. Which is why the two small words in front of the 1,400 matter more than the 1,400.

Do the arithmetic before you admire it. Assume a 40-hour working week, which is generous for a documentation team in peak season and fair for budgeting. Fourteen hundred hours divided by 40 is 35 people. That is the size of the prize being described at a UK site: thirty-five person-equivalents of keyboard work, gone.

Now read the qualifier again. Up to 1,400 hours. Up to is a maximum operator, not a mean. It is the best week in the sample, and the best week in a documentation queue is the week when arrivals spiked, which is exactly the week when utilisation was highest and the queue function was steepest. Build a business case on the maximum of a convex function and you have built it on the single least repeatable week you own. Suppose, and this is my assumption rather than anything in the announcement, that steady state runs at around 70% of the peak figure. Then the recurring number is closer to 980 hours, or about 24.5 person-equivalents. The gap between 35 and 24.5 is ten and a half people of expectation, and that gap is where automation projects usually lose their sponsors.

I am not saying the number is wrong. I am saying it is a peak reading of a queue, quoted as though it were a throughput rating, and those two behave very differently under load.

Why now is less dramatic than the framing suggests, and I would rather say so plainly. This is a vendor announcing a customer win on 20 October: no regulatory deadline behind it, no tariff change, no port closure. The timing that matters is internal. Pentagon ran this first at its UK operation, the UK operation produced the reference numbers, and those numbers are what make a Gulf deployment sellable. That is a normal sequence. The 1,400 hours, the 60% and the 40% are evidence about a UK documentation desk with UK labour costs, a UK software stack and UK customs procedure. They are not measurements of a Jebel Ali yard.

The two cost numbers also sit on different ledgers, and running them together is the easiest mistake in the whole story. Software cost down 40% is a sourcing outcome. Any site that swaps an expensive stack for a cheaper one gets something broadly like it, and that kind of saving travels. Clearance cost down 60% is not a sourcing outcome. It can only come from fewer rejections, fewer re-submissions, less dwell and less re-handling. If a vendor's 60% is mostly licence arithmetic wearing a different hat, then it does not travel to your site at all. Ask which ledger it sits on. Ask for the rework rate before and after. If a vendor cannot produce a rework rate, they measured the wrong variable, and the hours figure is decorating a gap.

The scope is where I would genuinely pay attention, because scope is a statement about where the vendor thinks the bottleneck is. Customs documentation and export documentation are obvious inclusions. Three others are not, and they are the interesting ones.

Oil country tubular goods inventory is the first tell. Pipe that goes downhole is graded, and a grade error is not a paperwork inconvenience, it is a failure inside a well. A per-item record carrying the specification next to the yard location solves a physical problem rather than a clerical one, and it is the piece of this deployment I would watch most closely.

Warehousing billing is the second. It is the only item here where a cargo owner sees the money directly, because storage charges follow where the cargo sat and for how long. Tie yard location and dwell time to the invoice and you remove an entire class of dispute, and disputes cost more than their face value because they eat the same human attention as a genuine exception. If I were the importer here, billing is what I would audit first.

Operational reporting is the third, and it is what makes the other two testable. Reporting is not the product. It is how you find out whether the queue actually moved.

Now the part nobody wrote, and the part I would want an importer to sit with.

The announcement says every piece of cargo keeps one auditable record: specification, yard location, HS code and declared content. Every trade publication will read that as traceability, and traceability is the good half of the story. The other half is that a uniform, machine-generated, per-item record is also an index. You have just built the query that a customs audit would most like to run.

Consider what manual inconsistency was doing for you, entirely by accident. When three clerks declare the same product three slightly different ways, you hold a distribution of positions. A sample-based audit lands somewhere inside that distribution: some right, some wrong, some arguable. Arguability is a hedge. You did not choose it, but it was working for you. Automate the declaration and the distribution collapses to a single point. Every declaration now says the same thing, in the same words, with a timestamp and a yard location attached. If that single point is right, you are in the strongest compliance position you have ever occupied. If it is wrong, you have filed one identical wrong position on every shipment, and the audit no longer needs to sample anything. It needs one query.

That is the entire game with HS codes. A classification error is not a typo. It carries duty, and in most jurisdictions it carries a penalty regime that looks at the pattern rather than the incident. Variance used to blur the pattern. Consistency sharpens it.

And here is the systems reason the exposure is sharper than it looks. The platform captures and validates across the commercial invoice, the packing list and the Bill of Entry. Validation of that kind is internal-consistency checking: do these three documents agree with each other. That is genuinely valuable, and it kills the single largest source of rework in documentary clearance, which is transcription. But transcription error is not source error, and cross-document checking cannot see source error at all. Those three documents descend from the same upstream record, the shipper's own order data. If the description, the grade or the classification is wrong at origin, all three inherit it perfectly, and the validator will report a clean match. Perfect agreement between three documents that share one ancestor is weak evidence, and an audit trail built on top of it does not strengthen it. It makes it uniformly, provably wrong.

Which is why the HS line in that per-item record is the one field that must not be fully delegated. Pulling a code off an invoice is an extraction problem and machines are good at extraction. Deciding which code applies is a classification judgement about the product, and it is the only part of this stack carrying legal exposure. I will leave the boundary of that judgement to people who live inside it: Derek Xu works this seam for a living, and where the data model stops and the declaration position starts is precisely the line he draws. What I will say from the systems side is narrower and testable. Somebody's name has to be on the classification. The machine's output has to be reviewable. New SKUs have to be reviewed by a human on first declaration. If nobody owns the code, you have not removed a bottleneck. You have moved the bottleneck to a place with no alarm on it.

Three things would change my mind about the value here, and all three are cheap to check.

If the binding constraint at that Jebel Ali site is physical rather than documentary, this project polishes a non-bottleneck. Tubular stock moves by crane and by crew. A yard has finite pad space and finite lift capacity. A free zone lets cargo sit outside the customs territory for a long time. If pipe is waiting on a lift rather than on a form, then faster paper buys you tidier paper and nothing else. Measure where the item actually waits before accepting anybody else's account of where it waits.

If the 60% is mostly licence arithmetic, it will not replicate outside the stack it came from, and you should budget for your own sourcing delta instead.

And if the freed hours get reinvested into volume instead of retired, the customer sees no improvement at all. A forwarder sells throughput. Take thirty-five person-equivalents out of a desk and the commercial answer is to push more files through it, driving utilisation back to where it began and the queue back to roughly its old length with more volume through the door. Good for the forwarder's margin, negligible for your clearance lead time. Ask what happens to the hours: retired, or redeployed? Those are two different projects wearing one press release.

For an importer or exporter, here is the path from this announcement to your own numbers. Documentation turnaround moves first and should move within weeks of go-live, because it is the direct output. Clearance lead time moves second, and only if the rework loop genuinely closes. Dwell time moves third and is worth the most money, because storage charges are computed on it. Inventory moves last and least: most importers size safety stock off a variance they have never measured, and a documentation system does not touch that variance. On an eight to twelve week parallel run plus cutover, expect the first two within a quarter and the third only after an arrival distribution goes into your own stocking formula.

Let me put numbers on it, with every assumption written down. Assume your Jebel Ali operation runs 400 declaration events a week. Assume each one consumes 3.5 hours of preparation, checking and rework handling across the team. That is 1,400 hours a week, and the match with the announced figure is deliberate: I have anchored the assumption on the only real number in the story so the arithmetic stays honest. Assume a 40-hour person-week. That is thirty-five person-equivalents of documented work.

Now the sensitivity, which is the actual deliverable. At 85% utilisation, time in system is about 6.7 service-times. Cut handling time by 40%, utilisation drops to roughly 51%, and time in system falls to about 1.2 shorter service-times: better than an 80% reduction in queue time, not a 40% one, because the intervention hits both terms at once. The good case is real.

Now change a different assumption instead: the rework rate. Assume a quarter of files bounce once, so effective arrivals are 1.33 times raw arrivals. Eliminate the bounce entirely and effective arrivals fall back to raw, a 25% reduction in load, which at high utilisation is also a large win. Both levers are strong. The difference is that the first is measured by a timesheet and the second is not measured at all, which is why business cases routinely claim the first and deliver neither.

And the downside case, same arithmetic. If your desk runs at 60% utilisation rather than 85%, the identical 40% handling-time cut produces a modest improvement rather than a dramatic one. A queueing benefit is not a property of the software. It is a property of the software multiplied by how full your queue already was. Measure utilisation before you sign anything.

So what would I actually do with this, sitting on the cargo-owning side.

Measure first, optimise second. Before any conversation about a platform, produce three numbers from your own last twelve months, and do not accept anyone else's substitute. Utilisation: weekly declaration events times actual handling hours, divided by weekly available hours, on the busiest desk you own. Rework rate: the share of files that went back at least once for a data mismatch, with the reason coded. And the tail rather than the mean: P95 documentation turnaround per file, because the average hides exactly the files that cost you the dwell. If you cannot produce those three from your own records inside a week, you are not ready to buy a system that claims to improve them, and no supplier should be in a position to tell you your own numbers.

Then fix the free things, because most rework in documentary clearance originates upstream and costs nothing to remove. Standardise the field set across the commercial invoice, the packing list and your own booking instruction, so that description, quantity, weight and origin are defined once and reused instead of re-keyed three times. Name an owner for the HS code by product family, with a written rule for what happens when the extracted code and the owner disagree, and that rule has to say the owner wins. Instrument the manual edit log now, before any system arrives, so that later you can measure zero-modification adoption instead of the adoption-with-edits figure every automation project reports. None of this costs money. All of it is a prerequisite. All of it gets skipped.

On the deployment itself, run parallel for eight to twelve weeks and treat the parallel period as the deliverable rather than the cutover. Set a field-level difference-rate threshold against the old record, I would use 2%, and refuse to cut over above it. Hold inputs to explicit thresholds: source documents complete at first submission in at least 95% of cases, yard location confirmed accurate on physical check in at least 99%, and every new SKU's classification reviewed by a named human on first declaration at 100%, no exceptions. If a site cannot hold those numbers, the system is not the problem, the upstream data is.

Then have the commercial conversation the press release does not have. Ask what happens to the freed hours. Ask for the rework rate before and after instead of the hours. Ask which ledger the 60% sits on. And put the queue metric into the agreement rather than the activity metric: what you care about is P95 clearance turnaround and dwell days, not how many forms the machine touched.

I will finish where I started. Think of it as a queue: arrivals, service time and a rework loop, with waiting time a convex function of how full it is. The 1,400 hours is a real number about a UK desk, quoted at its peak. It tells you that on a saturated desk removing handling hours is powerful. It does not tell you whether your desk is saturated, whether the 60% is operations or procurement, or whether the hours get retired or sold on as new business.

Where is the bottleneck, in your flow, at your site? That is the only question that decides whether any of this is worth money. Instrument three numbers, utilisation, rework rate and P95 turnaround, and you will know the answer inside three weeks for the price of a spreadsheet. Do that before the demo. Measure first, optimise second.

↑ Back to the key points

— By Ravi Chandran