The record nobody wrote down

The system that got installed still runs the way it always has. Somebody built it — a vendor, a contractor, a person who has since moved to a different company — and mostly it works, the way things left running mostly do: quietly, until someone needs to change it.

A supplier changes, a part number retires, a new line comes onto the network, and an engineer opens the configuration to make what looks like an obvious edit. Then finds a setting nobody remembers agreeing to, a threshold with no note beside it, a rule that might be load-bearing or might be a guess from a year ago. Nobody wants to be the one who finds out which. The edit turns into a support ticket, a meeting, a call to a number that may or may not still be answered.

None of this is a fault in the software. The software is fine. What is missing is the argument that produced it — why this threshold and not another, what was tried and set aside, who signed off and on what evidence. That argument lived in one person's head, and it left the building with them.

Why we build it this way

Most engagements ship two things: a working system, and a dependency. The system works for as long as the people who built it are reachable. The moment they are not — the contract ends, someone changes teams, the vendor gets bought — every change becomes a phone call, because the reasoning behind the system was never written down anywhere the customer can read it.

We think the actual deliverable of an engagement is not the software. It is the argument that produced the software: what was tried, what was rejected and why, what evidence justified each threshold and each design choice. A system without that argument is a box that happens to work today. A system with it is something your own engineers can change next year, for a reason they can defend to each other.

The obvious fix — write good documentation — falls short of this, because documentation describes what exists, not why it exists. A page can say what a setting does. It rarely says which alternative lost, and against what evidence. That is the part that actually stops a new engineer from breaking something they do not understand.

So we measure the end of an engagement by how little you need us afterward, not by how often you call. We would rather you called us for the next system than for a small change to this one.

How it works, roughly

Handover is not one meeting near the end. We run it as its own strand of the engagement, alongside the build, and it leaves your team holding a specific set of things:

• Runbooks that name what to check first when something behaves oddly, written for whoever is on call, not for the engineer who built it
• Escalation paths — who is contacted, and when, before a problem becomes an outage
• The written record of every decision made during the engagement: what was tried, what was rejected, and the evidence behind each call
• The test set your own domain experts helped build, so you can measure any future change, or any other vendor, against a standard you own

Training runs on the real system, with your own operators and engineers, while we are still there to answer for anything that does not make sense yet. When your team disagrees with a decision we made, the record shows what evidence justified it at the time — and if a new fact overturns that evidence, the decision changes on your say, not ours. Nothing is left sitting behind a support contract that keeps one vendor permanently necessary.

AI Transformation · drag to turn