Custody is Not Ownership

The page comes in at 3:14 a.m. Not because anything crashed—the system is still running, still doing exactly what it was built to do. It just hit a case nobody wrote a rule for, and instead of failing loudly it started quietly doing the wrong thing to real data. Someone on call clears the offending record, restarts the job, confirms the pipeline is moving again, and closes the ticket. Nobody touches the logic that produced the wrong behavior in the first place, because the person who got paged doesn’t have the authority to change it, and the person who does have that authority isn’t on the page list anymore.

That’s the failure worth examining. Not the outage. The fact that keeping something running and being answerable for what it does turned out to be two different jobs, held by two different people, and only one of them was still around.

---

Rigor Where the Risk Is Visible

Every organization running a mature ITIL practice can produce, on request, the paper trail proving this automation was done right. Change Management reviewed the risk before it went live—a Request for Change, an impact assessment, a Change Advisory Board weighing dependencies and blackout windows, a backout plan ready in case the deployment went sideways. Release Management scoped what was actually shipping—a defined, versioned unit, packaged and sequenced against everything else moving through the pipeline that week. Service Validation and Testing confirmed the thing worked before anyone trusted it with production traffic.

Look closely at what each of those gates hands off, though. None of them transfers authorship. They transfer the right to run the thing—to operate it, monitor it, restart it, escalate it. The design itself, the assumptions about what inputs exist and what to do with the ones nobody anticipated, stays with whoever wrote it, right up until that person’s mandate ends at deployment. Three rigorous gates, three sets of accountable owners, and every one of them is handing custody forward while authorship quietly evaporates.

This isn’t a failure of process execution. It’s a structural boundary. Change, Release, and Validation were built to answer “did this deployment follow the rules”—not “who is responsible for what this system believes about the world.” Those are different questions, and only one of them has a gate.

---

What the Record Can and Can’t Tell You

ITIL does have one discipline explicitly designed to survive deployment. Configuration Management exists to preserve reliable information about what’s actually running and how the pieces relate over the life of the service. Done well, an organization shouldn’t have to rediscover its own production environment every time something changes.

But even a well-maintained configuration record answers a different question than the one this essay is asking. It can tell you what an automation depends on, where it runs, what version is deployed, and what else might break if it changes. It cannot tell you who still owns the assumptions embedded in its logic—or who has standing to decide that one of those assumptions no longer holds.

That’s not a shortfall in Configuration Management. It was never the problem the discipline was built to solve. A perfectly maintained configuration record can tell you exactly what exists without telling you who remains responsible for whether what exists is still right.

---

What Vendors Don’t Hand Off

There’s an industry that already solved this, and it isn’t service management. It’s the software companies that build the tools every enterprise runs on. Microsoft doesn’t stop being responsible for Windows’ behavior once a customer’s IT department deploys it. Oracle doesn’t stop being responsible for the database engine’s behavior once a DBA is running it in production. Apple, Adobe, Alphabet—the pattern holds across all of them. A customer’s operations team manages use: patching schedules, uptime, access, configuration within the bounds the vendor allows. For the supported life of the product, the vendor retains authorship—the logic, the edge cases, the decision to fix or not fix a behavior when the world around it changes. Ops runs it. The maker stays answerable for it.

Nobody finds that arrangement strange. It’s the ordinary shape of software.

What is strange is how quickly that expectation disappears when the maker and the operator happen to work for the same company. Cross an organizational boundary instead of a contractual one, and suddenly the same handoff gets treated as though authorship went with it. It didn’t.

---

Being In-House Doesn’t Dissolve the Obligation

The distinction gets lost when the same organization builds automation for itself instead of buying it from someone else. Somewhere in that transition, the vendor relationship quietly disappears—not because the underlying obligation changed, but because there’s no invoice reminding anyone it still exists.

An in-house team is a dedicated vendor. The absence of a contract doesn’t eliminate the product lifecycle. The logic it wrote doesn’t become self-sustaining just because the org chart puts both sides under the same roof. But that’s precisely how it gets treated: the automation ships, the team that built it moves to the next project, and the business unit that requested it treats “automated” as a completed state rather than an ongoing relationship with a product that still needs an author.

What’s left running in production ends up under whatever ambient operational monitoring the organization provides for everything else it runs—which means it doesn’t reappear as anyone’s explicit responsibility until Incident Management goes looking for someone to answer for it during an outage. By then the question isn’t “who’s been stewarding this system’s judgment.” It’s “who broke this”—and those two questions belong to completely different disciplines.

The longer automation survives, the more dangerous that gap becomes. The environment changes. Interfaces change. Business rules change. Exceptions accumulate. The code keeps executing exactly as written long after the assumptions that made it correct have quietly expired. Nothing about that requires the system to be intelligent, adaptive, or new. It requires only that it keep running while nobody with standing authorship is still watching what it believes.

---

Custody Ends. Ownership Doesn’t.

Ask most organizations who owns a given piece of internal automation and the honest answer is operations—whoever’s on call, whoever gets paged, whoever restarts the job at 3 a.m. Ops can tell you whether the job ran. Monitoring can tell you whether it completed. The configuration record can tell you what it depends on. Incident Management can tell you what happened once somebody finally noticed. None of those answers the question that actually matters once a system’s assumptions have quietly expired: who is still responsible for deciding whether what it does is right.

The system in the opening didn’t fail. It kept working after it had stopped being right, which is a worse problem than a crash, because nothing about it triggers an alarm.

Ops keeps a system alive. The author keeps it honest. Collapse that distinction and the org ends up with systems everyone is watching and nobody is authoring—which guarantees that when the next 3:14 a.m. page arrives, the person looking at the logs may be perfectly capable of restoring service and still have no mandate to fix what’s actually wrong.