An EA team adopts a full content metamodel and records applications, their owners, their data entities, their hosting, their integrations and their lifecycle status. Maintenance is a quarterly email asking owners to confirm their entries. What does the repository look like in two years?

Second by second, what happens

Quarter one. The model is accurate, because it was just built, and it is impressive in a steering committee.

Quarter two. The first confirmation email goes out. Response rate is about 60%, which is the normal ceiling for an unrewarded request from a central team. The 40% who did not reply are recorded as unchanged, which is a silent assumption that their entries are still correct.

Year one. Apply a realistic rate of estate change: if roughly 8% of applications change owner, hosting or lifecycle status each quarter, and each quarterly refresh corrects only the 60% that replied, the share of entries that are wrong converges to something like a quarter of the model. The precise number does not matter; the shape does. Decay is continuous and correction is periodic and partial.

Year two. Enough entries are wrong that users start checking the repository against reality before trusting it, which doubles the cost of using it over not using it. At that point it stops being consulted, and because it is no longer consulted, nobody notices further decay. The model is now worse than absent, because it is cited in decisions by people who do not know its error rate.

Where it amplifies

The metamodel's breadth is the multiplier. Every additional attribute per application is another thing that can go stale, and attributes differ wildly in decay rate: a system's name is nearly static, its owner changes with every reorganisation, its hosting changes with every migration, its integrations change constantly. A model that treats all attributes as one maintenance task decays at the rate of its fastest-moving field.

What stops it

• Derive, do not ask. Owner from the code repository's owning team, hosting from the cloud provider's tags and accounts, integrations from observed traffic or gateway configuration, lifecycle from deployment activity. Anything derivable from a system of record should never be typed by a human.
• Keep only the attributes you can feed. Fewer fields, each with a named source and a refresh frequency, beats a complete metamodel maintained by email. This is the tailoring the framework tells you to do and that teams skip.
• Publish a freshness indicator per record, showing the source and the last-verified date. Users can then calibrate their trust, and a stale field is visibly stale rather than quietly wrong.
• Attach every attribute to a question. If no one has asked "which applications are hosted where" in a year, stop maintaining the field.
• Measure the model against reality on a sample. Pull 20 applications a quarter, verify every attribute by hand, and publish the error rate. An EA repository without a published accuracy number is an unaudited claim.

What would have to be true for this to self-heal

The repository would have to be on someone's critical path for a task they do weekly, so errors cost them personally and get fixed at the point of pain. That is why inventories embedded in deployment pipelines or access-request flows stay accurate while standalone ones do not. Put the register where the work happens, or accept that it is a snapshot with a half-life.

When not to pay for this

If the estate is small enough that the people in one room know it, the model adds nothing and the room is the inventory. Formal modelling earns its cost when no individual can answer an estate-wide question, and the honest first step is then two fed attributes rather than twenty typed ones.