The pilot nobody could fail

In September we said Lucid owns the distance from pilot to fleet. It was the one term in the vocabulary our research found genuinely unclaimed in maritime, and we spent four sentences on it.

Having since gone looking for where that distance actually breaks, we were pointing at the wrong end of it. The break happens at the purchase, months before anybody notices, and by the time the expansion stalls the cause is already a year old.

Maritime pilots get liked. They get renewed. They stay exactly where they are.

Speed and accuracy are the only test that gets applied

Start with what the desk is actually for.

In shipping, the operator's job is speed and accuracy. Fix it faster, get the figure right, keep the ship moving. That is what the business pays for and it is what the person at the desk is judged on, every day, by people who will notice within hours if either one slips.

So anything that threatens speed or accuracy is rejected outright, by the person using it rather than the person who bought it, usually inside the first week. The decision is made at the desk and it is close to instinctive.

Every new tool is slower before it is faster. There is a period where the old way is quicker and the new way is unfamiliar, and throughout it the thing on trial is failing the only test the desk knows how to run. Software gets adopted by surviving the window in which it is worse.

Nobody said what the pilot was for

A maritime pilot is typically signed off without a success metric. No statement of which decision or which workflow is supposed to change. No definition of what better would look like in the terms the desk uses. No milestones, and no gate anybody has to pass through before the next tranche of money or attention.

So the question "did the pilot work?" gets an impression instead of an answer.

Two other things are usually said about why pilots stall, and both are real. There is no skin in the game — the customer has risked little and can walk away at any time. And nobody invested in the change itself, as opposed to the licence. But both of those are downstream of the first problem. You cannot ask anyone to invest in a change you have not defined, and skin in the game means nothing when there is no agreed definition of winning.

A pilot with no defined outcome can only be liked.

Being liked is worth something. It renews. It produces a warm reference call and a champion who speaks well of you in the corridor. What it does not produce is a reason for a department that didn't buy the thing to change how it works.

Why it surfaces at the next desk

The missing definition stays invisible for as long as the software stays where it started, which is why everyone finds out late.

Inside the pilot function the friction gets absorbed. Those people asked for the tool, they wanted it to work, and they will carry the slower-before-faster window on goodwill alone. Nobody has to justify anything, because everyone in the room is already persuaded.

The next desk is a different proposition entirely, and here the word in our own term misleads. A fleet is a count of desks ashore, because this is office software — bandwidth at sea still decides what can run on a ship, so shipboard systems are the exception rather than the rule. That balance is shifting and we expect it to keep shifting, and it does not change the shape of the problem: a ship that can finally run software is one more place the work has to land.

Operations to chartering, chartering to post-fixture, post-fixture to agency. Different workflow, different counterparties, data arriving in a different shape, and frequently the benefit landing somewhere other than the desk being asked to change. The people there did not ask for this. They have no goodwill banked, so they apply the cold test on day one, and on day one the thing is slower.

And there is nothing to appeal to. Nobody can say we agreed this would take four hours out of the laytime calculation, because nobody agreed that. The only argument available is that the other team likes it, which is not an argument anybody has ever won.

Shipping publishes its own failure rate

The sector's answer to this gap is a superuser: a capable person inside the customer who likes the product, has a day job, carries no engineering authority and no mandate to tell another department how to work. The vendors who rely on that model are honest about the odds in their own marketing.

Veson deputises business process owners and superusers, and cites the finding that around 70% of failed digital transformations trace back to poor adoption. Sedna publishes a seven-step implementation method ending in hypercare with a formal exit sign-off, and cites that over 80% of workers feel anxious about new technology and processes. Both numbers are published by the vendor, next to the model they indict.

The research says it with a wider sample. Thetius and Marcura, surveying the industry in August 2025, found 81% of maritime companies running AI pilots and 11% with the policies and guardrails needed to scale them. Guardrails is a governance word. It is the thing a gate is made of, and nine out of ten companies running a pilot do not have one. The most-named barrier was inadequate training — which is what a workflow change looks like when nobody budgeted for it.

1

Marcura's own reading of its data is the whole argument in a sentence: AI readiness in shipping starts with understanding employee workflows, not with selecting a model.

There is a noteworthy difference between simply connecting systems and confirming they actually support decision-making.

THETIUS · MATT STEVENS · 4 JUN 2026

2

Confirming is the step that got skipped. The spend is real and climbing — 420 organisations were active in maritime AI last year, up from 276 — and almost none of it was released against a stated decision it was meant to improve.

3

Nobody owns the definition

The reason this keeps happening is duller than a conspiracy and harder to fix. Defining the outcome is in nobody's interest at the moment it would have to be done.

A vendor that insists on success criteria makes its own sale slower, smaller and conditional. A champion who agrees to a metric converts personal enthusiasm into a number they can be held to. A procurement function is set up to test price and risk, not to specify a change in how work is done. Implementation arrives after the definition should already exist and is scoped to deliver what was signed, not to question it. Everyone behaves rationally and the pilot starts without a target.

We spent five years on the vendor's side of this, running the functions that each own a piece of the problem and none of it. The diagnosis is work we have owned.

What has to happen before the money moves

The remedy is unglamorous and it is mostly refusal.

Name the decision or the workflow the software is supposed to change. One of them, specifically, in the language the desk already uses — this calculation, that handover, this recurring argument with a counterparty.

State what better looks like in the only terms the desk accepts. Faster by how much, more accurate against what baseline. If neither can be stated, the honest conclusion is that nobody yet knows what the software is for, and that is worth finding out before a contract rather than after a renewal.

Put gates on it. Points where the thing either passed or did not, with a named person who decides and a consequence attached to either answer. A pilot with no gate cannot be failed, and anything that cannot be failed cannot be used as evidence for anything else.

Then fund the window where it is worse. That is the part nobody budgets and the part that decides the outcome.

All of it is simple work that no one in the transaction is incentivised to do, which is why it reliably doesn't get done.

The definition has to come from outside the transaction

Everyone inside the deal is paid to avoid this work, which means it has to come from somebody who isn't in it.

A facilitator convenes a workshop and produces a document, and a document has never changed a laytime calculation. Whoever does this has to be able to say out loud, in the room, that the workflow is wrong — and then have the replacement built. Method without authority produces a success-criteria slide everybody agrees with and nobody is bound by.

It also has to happen before the contract, which is earlier than almost anyone currently sells into. Implementation teams arrive after the definition should already exist, scoped to deliver what was signed rather than to question it. By then the only honest options are to deliver the wrong thing well, or to reopen a negotiation nobody wants.

The obvious objection is that this makes the engagement longer at both ends — in before the money moves, out after the rollout. It does the opposite. The gate is the ending. A pilot with a named decision, a stated definition of better and a date when somebody says yes or no is an engagement that knows how to stop, which is the test we said in September we wanted to be held to. Work with no gate expands to fill the account, and that failure is ours to avoid as much as anybody's.

One limit, because it matters. This only works where there is a real decision worth improving. If the workflow is sound and the software is simply bad, no amount of definition rescues it, and the right advice is to stop paying for it.

Who pays for it

The honest answer is that the industry has not settled this, and any firm telling you otherwise is selling. For a vendor it is an expansion problem, which makes it a net revenue retention problem — a number already going to the board. For an owner it belongs to the transformation programme, which is funded, and is being spent on connecting systems rather than on confirming anyone uses them.

The counter-argument belongs here rather than left for someone else to raise. Nautilus Labs raised over $48 million, reportedly had demonstrable product-market fit, and was sold to Danelec in late 2023 while running out of cash, with around seventy people made redundant first. Profitability killed it. So this has to replace an expensive sales-and-services motion rather than sit on top of one — and any version of it that becomes permanent capacity has reproduced the problem it was hired to solve.

4

The test

So the test we would like to be held to is the same one as last time, pointed somewhere earlier.

Whether anybody can say, without reaching for it, what the thing was supposed to change — and whether that was written down before the money moved. The measure after we leave is unchanged: what the customer still runs a quarter after the final invoice.

If your product has been live on one desk for a year and everybody there likes it, look at the pilot. It never had a gate.