What are the most common ways a context map fails to reflect reality in a mature system, and how do those failures typically surface — as slow rot, or as sudden production incidents?

## The two families of failure A context map's failure modes cluster into two families: | Family | What went wrong | |---|---| | **Failures of creation** | the map was wrong the day it was drawn | | **Failures of maintenance** | the map was right once and has since drifted | Both are common in any system with real production age, and both typically manifest the same way — quietly, for a long time, until a specific change collides with the gap and produces a visible incident. ## Creation-time failures Creation-time failures happen because building an accurate map depends on the people in the room knowing about every real integration, and in any system that's existed for more than a year or two, some integrations are informal enough that they're not common knowledge even among the teams involved. A classic example is a direct database read added under deadline pressure — a reporting job that needs a field the public API doesn't expose, so someone grants read access to another team's schema as a 'temporary' fix that becomes permanent because nobody circles back. If the engineer who added it isn't in the mapping workshop, or has since left the company, that integration simply doesn't appear on the resulting map, and the map is wrong from day one in a way that looks, to everyone who consults it, exactly like a correct and complete document. ## Maintenance-time failures Maintenance-time failures happen even to maps that were fully accurate when drawn, because systems keep changing after the map is finished: - a new integration ships without anyone updating the diagram; - a bounded context that used to be one thing splits into two during a refactor; - or a reorg hands ownership of a context to a different team without the map's ownership labels being updated. None of these changes announce themselves to the map; the map simply becomes progressively less true the longer it goes unrevisited, and because there's no natural signal that a diagram has gone stale, this kind of drift can persist for a very long time completely unnoticed. ## Why it is more than a documentation problem The reason both failure types matter in practice, rather than being a purely cosmetic documentation problem, is that a context map is trusted precisely because it claims to describe reality — teams use it to decide whether they need to coordinate before making a change. A wrong or stale map doesn't just fail to help; it actively misleads, because the confidence it projects is disconnected from the accuracy underneath it. ## The trade-off This is the key trade-off in relying on any context map: it's strictly better than no shared picture at all when accurate, but the moment it goes stale it becomes actively worse than having no map, because 'no map' at least prompts an engineer to go check, whereas a wrong map short-circuits that check with false reassurance. ## How it surfaces in production Both failure families surface in the same recognizable way in production: they're invisible until a change is made that trusts the map's account of what depends on what, and a real, unmapped dependency turns that trust into an incident. The postmortem pattern is distinctive and repeats across organizations: 1. a team makes what the map says is a safe, isolated change; 2. a downstream system that the map doesn't show as connected breaks; 3. investigation reveals an integration that either was never captured or was captured accurately once but the map was never updated after a later change introduced it. The visible cost of the failure — a production incident, an angry customer, an emergency rollback — always arrives much later than the quiet moment the map first became wrong, which is exactly what makes this failure mode dangerous: there's a long, silent gap between cause and consequence, during which the map keeps being consulted and trusted. ## A concrete scenario A concrete scenario: a company's context map, drawn eighteen months ago, shows an Inventory context with no downstream consumers of its internal 'reserved quantity' field beyond the Orders context it was designed for. A Fulfillment team, formed during a reorg after the map was drawn, quietly built a nightly job reading that same field directly from Inventory's database to compute a warehouse capacity report — an integration that exists in production but on no diagram anywhere. When the Inventory team refactors that field's semantics as part of an unrelated cleanup, trusting the map's claim that only Orders depends on it, Fulfillment's nightly report silently starts producing wrong capacity numbers for two weeks before anyone notices the discrepancy — a slow-burning version of the same underlying failure, made worse because it wasn't even a sudden crash that would have triggered an immediate investigation.