Photo by Ishan @seefromthesky on Unsplash

There is a particular sentence that appears in incident reviews, architecture meetings, postmortems, and inherited projects with remarkable consistency.

“That predates me.”

And usually, it is true. The person saying it did not make the decision. They were not in the room when the architecture was chosen, the exception was granted, the workaround became permanent, or the process acquired its unconventional extra step. Sometimes they joined the organization or team years after that moment. Often, everyone who actually made the decision has left the company.

The interesting part is not the sentence, but what happens to the room after someone says it.

There is often a lessening of tension that follows. Nobody announces it, and the action item doesn’t close itself, but something has been discharged. The decision belonged to someone else, and the person who made it is gone, so no one currently present can reasonably be blamed for it. Since blame has nowhere useful to go, the conversation begins to move on.

There is just one problem with that outcome: The decision is still running in production.

Its author may be gone, but its consequences are still part of the environment. The system still routes through it, and processes still depend on it. The exception still shapes behavior, so the architecture still carries the tradeoff.

Whatever was decided years ago survived the people who made the decision, and it has now, apparently, survived the meeting that was supposed to examine it.

That is where organizations make a subtle category error: They confuse authorship with custody.

Two Things a Decision Leaves Behind

Every consequential decision leaves at least two things behind.

The first is authorship. Someone, at some point and for some list of reasons, made the decision.

Maybe it was one person, or maybe it was a committee, a leadership team, an architect, a developer, a hurried project group working under constraints nobody remembers. Whatever the case, authorship belongs to the moment in which the choice was made.

It is historical, and it does not transfer.

If I inherit a system built ten years ago, I do not become the person who chose its database technology, approved its shortcuts and stored procedures, designed or accepted its security model, or defined its original operating assumptions. I can no more inherit authorship than I can inherit the date on which the decision occurred.

The second thing is custody. Custody is fundamentally different in that it belongs to the present.

It rests with whoever now has the practical authority and/or obligation to maintain, defend, improve, replace, or deliberately preserve the decision. Unlike authorship, custody transfers constantly; usually without ceremony.

There is rarely a formal moment when someone says, “You are now responsible for understanding why this exception exists,” and even less often one where you are handed a box labeled Inherited Architectural Decisions. There may not even be a handoff between the old custodian and the new one.

One person leaves, another arrives, and the system itself changes very little. Custody has moved.

This is why “that predates me” can be simultaneously true and insufficient. It answers the authorship question, but says nothing about custody.

Those are different questions.

Innocence Is Real

This distinction matters because the opposite mistake is just as easy to make.

People should not be blamed for decisions they did not make. That is not just a polite management practice, but a basic requirement of fairness.

A person who inherits a poorly designed process did not retroactively design it. A new architect is not guilty of every shortcut embedded in the platform they inherited, just as a manager who arrives after years of neglected maintenance cannot reasonably be treated as though they personally chose to defer the costs.

Often, the new person also lacks the context necessary to explain what they inherited, and few would call that negligence.

Institutional knowledge can decay for a variety of reasons: documentation is incomplete, people leave, and conditions change. Some decisions were never written down because, at the time, everyone involved understood them. Others were documented badly, while others were made under pressure and remembered only as a sequence of conversations whose participants are no longer available.

There is real innocence here, and it should be acknowledged.

More importantly, it should teach us that guilt is usually operationally useless.

Finding the person who deserves historical blame does not restore missing context, fix a broken process, or tell us whether inherited constraints still matter. Custody is therefore not a moral accusation.

It is the difference between You caused this and This exists now, and you are responsible for what happens next.

That is a much more specific claim, and a much harder one to escape.

The Handoff That Never Happens

Organizations are remarkably good at transferring artifacts.

Repositories, access groups, dashboards, and runbooks survive. Even tickets, diagrams, spreadsheets, SharePoint sites, exceptions, standards, and approval records tend to accumulate long after their authors disappear.

What transfers less reliably is the reasoning that gave those artifacts meaning. A document can tell us what was decided, and it may even tell us why. What it rarely preserves well is the full boundary around that why.

“This process must remain manual until the automated source is validated.”

Fine. What counts as validated?

“The legacy integration must remain available until the replacement supports all required transactions.”

Which transactions were required?

“This exception is necessary because the vendor cannot support the standard authentication method.”

How will someone five years from now know when that statement stops being true?

The decision survives because it is concrete, but its ending condition decays because ending conditions often depend on context. The person who wrote the exception may have known exactly what evidence would make it unnecessary, but the person inheriting it sees only the exception.

This is one of the less recognized forms of institutional memory loss. Organizations often preserve the rule more successfully than the condition that justified it, until, eventually, the surviving artifact begins to look self-explanatory.

It never is.

I have written before about the half-life of judgment: a durable rule keeps running past the boundary that made it valid, because the organization forgets the boundary faster than it forgets the rule. I have also written about borrowed simplicity: every exception borrows simplicity from the future, and the cost never gets booked.

Both of those arguments assume the person who made the decision is still somewhere in the picture – still able, in principle, to be asked. This one does not. What is at stake here is transfer: the moment the rule and the exception both outlive their author, and the only thing that actually changes hands is the artifact.

The system remembers the answer, but it eventually forgets the question.

Deference and Demolition

The absence of context creates two opposite failures.

The first is deference – someone encounters an old architectural decision and assumes it must remain because there was probably a good reason for it. Sometimes, even often, there was.

The original designers may have understood constraints that are no longer visible. What looks inefficient now may have begun as an elegant response to licensing, performance, staffing, vendor limitations, regulation, delivery pressure, or incomplete infrastructure.

“There must have been a reason” is therefore not foolish. It is epistemically cautious, but caution can harden into reverence; at some point, an unknown historical reason becomes an all-purpose defense of the present arrangement. Nobody can explain why the thing exists, but nobody is willing to question it because questioning it might reveal why the thing exists.

The second failure is demolition – a new person arrives, sees something awkward, and removes it. The logic is equally understandable: the architecture is inconsistent, the exception violates the current standard, the extra step appears redundant, or the workaround looks ridiculous.

Why would anyone design it this way?

So the new custodian cleans it up, and something downstream breaks. The important point is that deference and demolition look like opposites, but they arise from the same missing input.

Neither understands the function of the inherited decision. One preserves the decision because its rationale is unknown, while the other removes the decision because its rationale is unknown.

The epistemic error is identical.

A successor never inherits the original decision in its original form; instead, they inherit its compounded form.

Years of dependencies may now rest on it, and conditions may have changed. Other systems may have incorporated its outputs, meaning a temporary accommodation may have become structural. A good decision may have become obsolete, or a bad decision may have become expensive to reverse.

The question is therefore not simply: Was this originally correct?

Nor is it: Would I make this decision today?

The better question is: What is this decision doing now?

I Am On Both Sides of This

It would be convenient if this were an essay about other people, but few of mine ever are. I spend a significant amount of my professional life inheriting decisions.

Some were made under circumstances I would not choose today. Some encode assumptions that no longer hold. Some optimize for priorities that have changed.

That does not mean they were mistakes.

A structure built when delivery speed was the overriding constraint may have been exactly the right structure at the time. Years later, the same structure may create drag because the environment around it has matured.

It would be easy to look backward and confuse present inconvenience with past incompetence, but that would be both unfair and intellectually lazy.

But the argument runs in the other direction too; I am the one authoring decisions now, whether standards, architecture, or governance practices. I can explain why they make sense because I am standing inside the context that produced them, and someone else will eventually inherit them without that understanding.

To that person, some of what I am doing will appear overly cautious, unnecessarily complicated, insufficiently formal, too centralized or too distributed, too manual, or built around constraints that are no longer obvious.

And I will not be there to explain myself.

The temptation is to believe that good documentation solves this, and it does help, but it can never be a complete solution. I can document what I believe today, but I cannot document every future condition under which that belief should be reconsidered.

Even a doctrine that explicitly says, “This should evolve as needs change,” leaves an important question unanswered: Who is responsible for noticing that the needs changed? A principle without future custody is merely an instruction waiting to become an artifact.

I can write the very thing this essay is warning about. Probably, eventually, I will.

The best I can do is make that inheritance less blind.

The Claim

The solution is not another register for tracking decisions. Organizations already produce enough logs, and not every inherited decision needs a five-field form, an owner column, a review date, a risk score, a color code, and a workflow that ensures the form itself will someday become another unexplained artifact.

Custody is established in the present. It is a claim made by people who are willing to answer for what an inherited decision is doing now. For any load-bearing decision, three questions are usually enough to expose whether that custody exists.

First: What does this still buy us? Not what did it buy us in 2021, but what does it buy us now?

What constraint does it satisfy? What risk does it control? What dependency does it support? What failure does it prevent? What useful tradeoff are we still receiving in exchange for its cost?

Second: What would tell us it had stopped?

This is the question old decisions are least likely to answer. What observable condition would make the exception unnecessary? What changed assumption would justify replacing the architecture? What capability, threshold, migration, contractual change, staffing level, reliability target, or control would tell us that the original tradeoff no longer makes sense?

A decision without an ending condition is unusually good at becoming permanent.

And, finally: What happens if nobody touches it?

Some decisions decay safely; others accumulate consequences. A deprecated component becomes unsupported. A manual workaround becomes a hidden dependency. An exception expands. A permission model drifts. A temporary integration quietly becomes the only surviving path between two systems.

Inaction is not neutral simply because nobody made a new decision; sometimes inaction is the decision.

If nobody can answer these questions, the system may still have an owner on paper, but the owner does not yet have meaningful custody. That does not mean the inherited decision should be removed, but it does mean that it should be scheduled for understanding.

There is an important difference: Unknown is not the same thing as wrong, it is just unfinished.

There is also a simple diagnostic available to almost any team. Listen to the explanations in your next architecture or process review.

Count how many are historical:

• “We did it that way because…”
• “That was built before…”
• “The old team needed…”
• “That predates…”

Then count how many are functional:

• “We still do this because…”
• “This currently protects…”
• “We would remove this when…”
• “This remains necessary until…”

The ratio between those two kinds of explanations should tell you something about the system. Historical explanation identifies authorship, while functional explanation demonstrates custody.

This is not an argument against history. Recovering the original constraint is often the fastest route to a functional answer, and if the author is still reachable, going to find them is itself a custody move rather than an exercise in blame. But history can only tell you what the constraint was. It cannot tell you whether the constraint still binds.

The more heavily a system depends on the former, the larger its custody gap has probably become.

What the Room Was Actually Doing

Return to the incident review.

“That predates me.” The statement was true, and it mattered. The speaker should not have been blamed for a decision made before they arrived, but the room made a mistake when it treated the truth of the sentence as resolution.

The absence of the author did not change the behavior of the system, any more than the departed employee took the dependency with them when they left.

History explained how the decision arrived, but it cannot decide whether it should remain. That responsibility belonged to the people still in the room. It is not productive to hold people accountable for choices they did not make, but it is necessary to recognize that systems do not care who deserves blame.

They continue executing, producing consequences, and carrying yesterday’s tradeoffs into tomorrow until someone decides otherwise.

Innocence is a fact about a person, while consequence is a fact about a system. Only one of them changes when the staff does.

Nobody here caused it. Somebody here owns it.

Those have never been the same sentence.