Who Owns the System When the Builders Leave

For two weeks, a finance team handled a new supplier's invoices by hand, next to a system built to handle them. Six months after handover, the business had started buying from a new kind of supplier whose invoices needed a slightly wider tolerance. The team was unsure whether they were allowed to change it, who should approve the change, and how they would know if they had broken something. So they changed nothing, and then their finance lead called us.

The handover documents were complete and accurate. They did not transfer the one thing ownership actually means: the confidence and the authority to change the system without asking the people who built it.

We changed how we hand over after that call. The measure we use now is blunt. The quality of a handover is set by the smallest change the client's team is afraid to make.

Documents transfer knowledge, not authority

A typical handover pack describes how the system works: architecture, data flows, runbooks for known failures. It answers "how does this work". It does not answer the questions a team asks when the business changes: may we change this, who has to agree, how will we know it still works, and what do we do if it does not.

Without those answers, a careful team does the careful thing, which is nothing. The system freezes in its handover-day shape while the business keeps moving. A frozen system looks like a success right up until it is quietly replaced by a spreadsheet.

The change matrix makes authority explicit

The core of the handover is now a change matrix: the kinds of change the business will need, and for each, who may make it and what must happen first. It has three columns.

Changes the team makes alone. Adding a supplier mapping, adjusting a tolerance within a band the controller approved, adding a reason code, updating a routing table. The system checks the change against its limits and runs the relevant acceptance cases. If they pass, it goes live.

Changes that need a second person. A new matching rule, a new exception cause, a tolerance outside the band, a new approval threshold. One person makes it, a named reviewer approves it, and the full acceptance set runs before release.

Changes that need re-qualification. A new model version, a new document type, a new entity or market, a change to what goes straight through. These get a qualification run with a written comparison of results, and the process owner signs off.

The matrix is short, specific to the system and signed by the process owner. It turns a vague sense of risk into a rule anyone can look up. The tolerance in that phone call belonged in the first column. Nobody had told the team.

Every changeable part has a named owner

A part nobody owns cannot be changed safely, because nobody can say yes. So every changeable part has an owner on the client's side: the acceptance set, the thresholds and tolerances, the prompts, the model version, each integration and its data contract, the exception causes and reason codes.

Owners are roles with a named person and a deputy, so a job change reassigns the role instead of orphaning it. The acceptance set is the ownership that matters most. It is the safety net that lets people who did not build the system change it with confidence. Whoever owns it owns the ability to change everything else, which is why we never hand over an acceptance set that only we can run. If running it needs our environment, our scripts or our knowledge, the client does not own the system.

Changes are rehearsed before the builders leave

Reading how to make a change is not the same as having made one. In the last weeks of every engagement, the client's team makes a real change from each column while we watch and stay quiet: a mapping added alone, a rule added with a reviewer, a qualification run on a candidate model version. Each goes through the full process, acceptance run and approvals included.

Rehearsals find the gaps in a handover faster than any review. A step obvious to us and unclear to them. An approval nobody knew how to give. A test that takes too long to run in a normal working day. Each gap is fixed while we are still there to fix it.

Support follows the business calendar

A finance workflow does not need the round-the-clock on-call a public website needs. It needs someone available when finance works, and more so at month-end. The handover names the first responder on the client's side during business hours, what they may do without escalating, and the escalation path during the close.

Ownership is the ability to change

A client owns an AI system when its own people can change it as fast as the business changes. The smallest change they are afraid to make is the distance still to go.