Your application inventory records an owning team for each of 180 applications. A reorganisation dissolves 9 of 34 teams and redistributes their people across the remaining ones. Nobody updates the inventory. What happens over the following year?

What happens, step by step

Day one: nothing. The records still read owner: Payments Platform. Every report is green. The inventory's quality dashboard shows 100% ownership coverage, because coverage is measured as "the field is populated".

Weeks one to eight: the people who used to run those applications are now in other teams with other backlogs. The applications keep running - that is what makes this slow. Nobody has decided to abandon them; the decision was never taken by anyone.

First real event, typically two to five months in: something needs an owner. A certificate approaches expiry, a vulnerability scan raises a finding, a vendor announces an end-of-support date, an invoice needs approving. The process does what it is designed to do and routes the item to the recorded owner, which no longer exists. The ticket does not fail loudly; it sits. Somebody eventually walks it round the organisation by hand, which takes days per item.

By month six to twelve: a stock of these items has built up, and the organisation has learned the workaround - ask around. The inventory is now known to be unreliable, which is worse than being known to be incomplete, because an unreliable record still suppresses the alarm a missing one would raise.

The mechanism

A record that points at an abstraction fails quietly, because nothing validates it. "Payments Platform" is a string. Strings do not stop existing. The identity directory knows the team was dissolved and the inventory never asks it.

That is the whole lesson: an ownership field is only as reliable as the thing it points at is able to disappear noisily. An individual leaves and the directory deactivates the account. A rota has a pager that goes unanswered. A group in the identity provider is deleted and every reference to it resolves to nothing. A free-text team name has none of these properties.

Why the other options fail

• "The next refresh flags it." This is the comforting answer and it depends on how the refresh works. A refresh that emails owners asking them to confirm their entries sends mail to a group that no longer exists, gets no reply, and records no response - which most such processes treat as "unchanged" rather than "broken". A refresh that reconciles against the identity directory would catch it, and that is exactly the mechanism most inventories lack.
• "Cost allocation breaks at once." It would if the chargeback keyed off the same field, and in most organisations it does not - cloud cost flows from account and tag, and licences flow from a contract record. Finance keeps getting its numbers and has no reason to notice.
• "Security patching stops and the scan raises findings." The scan does raise findings; that is the trigger in month three. But the finding is raised against an application, not against the gap - so it becomes one slow ticket rather than a systemic alarm. Treating the vulnerability queue as the ownership-detection mechanism is how organisations discover this a year late.

What stops it

• Point the owner field at an identity the directory can invalidate - a group reference or a rota, not a typed name - and reconcile nightly. Unresolvable owner is a hard error with a named escalation.
• Make ownership a property of the code, not of a central table. A descriptor file in the repository is updated by the change that alters reality, and a dissolved team's repositories still resolve to real people through code ownership.
• Measure unresolvable owners, not populated fields. The first number is a fact; the second is a formatting check.
• Treat a reorganisation as a scheduled data migration. The list of dissolved teams exists on the day the reorganisation is announced. Reassigning 9 teams' applications is an afternoon's work in that week and a year of archaeology afterwards.

When this is the wrong answer

Below about 20 applications, everyone knows who owns what and the register is a formality; the reorganisation is handled in a conversation. The mechanism starts to matter at the point where no single person can list the estate from memory, which in practice is somewhere between 30 and 50 applications.