The pilot that ran on borrowed hardware

The pilot ran for six weeks in a cloud account that belonged to the vendor, not the plant. Everyone who sat through the demo agreed the numbers looked right. The contract that followed named a go-live date and left the question of which servers would run the thing for later, after the budget cleared — a detail that felt administrative at the time.

Later arrived, and so did a rack of new machines in the plant's own server room, under the plant's own locks. The model moved onto them, and so did the queue of documents it had to read, this time crossing the plant's own network instead of whatever the vendor had wired up for the demo. The number that had looked right for six weeks went looking for itself again, on hardware it had never met. Nobody who had sat through the pilot could say whether the new number was wrong, worse, or simply what the system had always been — and the cloud account had been measuring something else the whole time.

Why we build it this way

A number that only holds on a machine you are about to leave is not a number about your system. It is a number about the vendor's hardware, dressed up as evidence about yours.

The usual shortcut is to pilot cheaply in somebody's cloud, prove the idea fast, and migrate to the customer's own hardware once the budget clears. It is quick to start, which is most of its appeal. But a migration does not just move files — it changes where the model runs, who can see the data on its way there, and what you can put in the boundary document you hand an auditor. A number measured before that migration describes a system you are already leaving.

So we install on the hardware the customer will keep, inside their own network, from the first day — even when racking a server takes longer than opening a cloud account. That is the part people notice at the start. What they notice later is that the number never has to reset.

How it works, roughly

The first phase builds a test set from the plant's own hard cases — the ones people already argue about — and that becomes the definition of good for everything after it. The second draws the boundary: where the data sits, where the model runs, what crosses, who approves each crossing. The third installs on the customer's own hardware, and nothing about the first two phases gets re-measured when that happens, because it was never measured anywhere else to begin with.

What a plant head sees, every week from that point:

• the same test set, read on the same machines, the whole way through the build
• a published number, not a forecast from a different environment
• a stated moment to raise a flag — when the number stops moving, that gets said in writing, not left for someone to notice later

When a person disagrees with the number, or wants it to move faster, the test set is theirs to push back against. There is no earlier, better-looking number from before a migration to point them toward, because there isn't one — the hardware never changed under them.

AI Transformation · drag to turn