Testing the patterns on real material

Where this came from

The previous article on context debt concluded by acknowledging a limitation. The five patterns described were based on one fictional company within a single demonstration. That text suggested that future research should test those same patterns against real-world material. This report contains the results of that test.

There's no client material to publish here, so the real material is the next best thing available and fully verifiable: this site's own Flask codebase. Every claim below can be checked by anyone with the repository, which is closer to "we tested this" than most audits get to be in public.

The subject

The site's app.py needs to know, in several different places, which routes exist: which pages belong in the sitemap, which demo slugs are valid under /work/, which tool slugs are valid under /tools/, and which case studies have a custom diagram embedded in them. None of that information lives in one place. It's copied into four separate, hand-maintained lists, each written independently of the actual route table Flask already builds from the @app.route decorators themselves.

The finding

This is the same pattern as No Record, from How context debt shows up, just showing up in a codebase instead of an HR handbook. A real, current state exists (which routes the app actually serves) and is accurate at any given moment. But the systems that need a derived version of that state, the sitemap generator, the 404 handler, the diagram-loading logic, don't read from the source of truth. They read from a hand-copied version of it that has to be kept in sync by whoever adds the next route remembering to update every list that needs to know about it.

The current state of these lists does not contain any errors. Both were accurate during the most recent review. This situation represents the typical structure of context debt before it becomes an active issue. The information is correct for now, but there are no systems to provide alerts or errors when someone fails to update it. Neither the sitemap nor the 404 page has a mechanism to detect when they no longer match the actual site structure. The uncurated response in the support-context demo was also technically accurate upon initial inspection. However, it omitted a piece of information required by a downstream system. This is the same pattern occurring in a different area.

This site follows this pattern in practice rather than just in description. Building the Research section required manually updating three of these four lists at once: static_pages, TOP_LEVEL_SECTIONS, and the 404 slug logic, because these components do not update automatically.

What this doesn't mean

This isn't an argument that hand-maintained lists are always wrong. A list that's read often and touched rarely, by one person, who wrote the pattern this article is describing, is low-risk context debt. The Context Debt Map's own worked examples (a 2019 policy nobody updated, an approval that lived only in a Slack DM) are what the same pattern looks like at a company's scale, across more people, over more years, with no one person holding the whole picture. The mechanism is identical. The blast radius isn't.

The actual fix, if it's worth making

Flask already exposes the real route table as app.url_map. Deriving static_pages, WORK_DEMO_SLUGS, TOOL_SLUGS and DIAGRAM_EMBEDS from that (or from the content directories directly, the way load_all_articles and load_all_research_articles already do) would remove the "remember to update this too" step entirely. That's a real, scoped code change, not a rewrite, and it's the natural next thing to apply once this finding exists: an audit that ends in a fix, not just a name for the problem.