Urban debt and renewing the city without evicting it

No company can close for renovations. Urban debt is the set of constraints on change that builds up when infrastructure fragments, capabilities get duplicated, flows turn opaque, components are abandoned and governance exceptions stop expiring. You pay it down the way an inhabited city gets renewed, block by block with operations running, choosing each block by the status of its buildings and putting an expiry date on every exception.

Northstar Consumer Group, a fictional regional manufacturer and retailer, has five legal entities, an ERP, country-specific applications, more than forty analytics products and twelve experimental agents. None of it can be switched off over a weekend to be tidied up.

Where the debt comes from at Northstar

All five sources are present at Northstar, and none of them was a bad decision on the day it was made.

The first two are easy to confuse. Fragmented infrastructure is a service that should be common and got built several times over. Northstar has three notification implementations, and any rule that touches messaging has to be changed and tested in each of them. A duplicated capability hides better, because each copy looks legitimate from inside its own building (the application, service or model that delivers it). Margin gets calculated three different ways. Each formula has an owner in its district, the business capability it belongs to, and none of those owners has any authority over the other two formulas.

Opaque flows and abandoned components share a symptom: readers nobody has on a list. The BI tool queries ERP tables directly, so does a country application, and several integrations log in with the same service account, svc-integracion, so the access logs can’t tell you which one read what. Among the forty-plus analytics products there are also dashboards nobody opens and nobody dares switch off, because nobody knows whether someone still needs them. Each one keeps its permissions and its queries against the subsurface (the data, metadata, lineage and semantics that applications depend on). The day the ERP owner wants to change a table, there will be no way to know how many of those readers will break, or which of them matter.

The fifth source, governance exceptions, is the one that gets recorded least. An exception is permission to skip a city rule for a limited time and a stated reason, granted by someone with the authority to grant it. It turns into debt when the time limit disappears. The Northstar case doesn’t say whether anyone formally authorized the purchasing agent and the collections assistant to run on credentials inherited from a developer, or the BI tool to read ERP tables. It says that’s how they run today, and nothing in the case says when that will stop.

Debt that lives between buildings

The framework defines urban debt as accumulated structural cost that restricts change and raises operational risk. It presents it as an extension of technical debt to the territory, the strategic, legal and risk perimeter inside which the enterprise sets its rules.

The loop at the bottom isn’t part of the framework, and I should say so. I draw it because it’s the pattern I’ve seen repeat most often. When changing something through the formal route costs too much, someone requests an exception or builds an informal settlement (a useful solution built outside the shared architecture and controls), and that shortcut becomes the next source of debt. DWU has two pieces close to it, proposition P5 and the reciprocal relationship between low habitability and settlements, and digital habitability puts both into one loop.

The literature on digital options and debt had already taken debt beyond code. Standardized services create future development options, while unmanaged exceptions, duplicated components and tightly coupled integrations restrict change and affect reliability or firm performance (Ramasubbu & Kemerer, 2016; Rolland et al., 2018; Banker et al., 2021). Leavell (2026) adds interpretive debt, the interpretive compromises that pile up in layers. Northstar’s three margins fit there. The ERP records a sale, the BI tool interprets it one way and the commercial dashboard reinterprets it another.

What “urban” adds, in my view, is location. The technical debt inventories I’ve seen are kept per building. Each team logs outdated libraries and missing tests in its own backlog. Of the five sources, three live between buildings (fragmentation, duplication and opaque flows), abandoned components have no backlog because they have no owner, and exceptions live in governance decisions that no repository records. The commercial dashboard team could close every debt ticket it has, and the dashboard would still read ERP tables with no contract and compute its own margin.

To pay it down, DWU’s eighth principle, continuous renewal, frames legacy modernization as managed urban renewal. The idea predates the framework and comes from the information-system urbanization tradition, which already took for granted that the system gets renewed while people live in it.

Renewing with people still inside

Full replacement is tempting because it promises to pay off all the debt at once. It’s rarely possible. Digital infrastructures are relational, embedded in other structures, path dependent and hard to redesign from scratch (Star & Ruhleder, 1996; Hanseth & Lyytinen, 2010; Tilson et al., 2010). While the replacement is being built, the old city keeps taking orders and piling up new dependencies. A migration from SAP ECC to S/4HANA is a well-known case, and in the business won’t wait for S/4HANA (in Spanish) I explained why double maintenance usually means freezing functional changes on the old system right when the business asks the most of it.

The alternative is renewal by blocks.

The order of the blocks

I use “block” as a unit of work, a small group of buildings with shared dependencies that can be worked on within one portfolio cycle without stopping everything else. It resembles the îlot of the French-speaking tradition, although the îlot partitioned the system and this one organizes the work. To choose the order I rely on the building registry I described when zoning by business capability, where every building carries one of four statuses. The status doesn’t decide for anyone, but it tells you which question to ask first. The table is my own heuristic.

I start with abandoned properties because retiring them is cheap and each retirement removes a reader from the subsurface. Legacy installations come later, and they’re rarely replaced outright. First they go behind a governed route (an API, an event or a queue with a contract and monitoring), and only then does anyone decide whether to relocate or retire them. It’s the logic of the integration layer I described in extending a 20-year-old SAP ECC without exposing it (in Spanish), where the migration swaps adapters and the channels never notice. The diagram puts four Northstar buildings on a timeline, with daily operations running underneath.

Exceptions with an expiry date

The commercial dashboard row interests me most, because a strategic landmark carries debt too. Nobody would propose retiring it. Even so, it reads ERP tables outside any contracted route, and in the case nobody ever recorded that read as an exception, so it has no end date either. In infrastructure before density I proposed that every exception to a common service carry a reason, the accepted risk, a sponsor and an expiry date. This is what that read would look like if Northstar recorded it today on the same terms.

# Illustrative exception record for the fictional Northstar case.
# No standard behind these fields.
id: exc-commercial-dashboard-erp-read
status: active                   # active | expired | renewed | closed
rule_waived: read ERP data only through routes with a contract
building: commercial-dashboard
district: commercial
scope:
  reads: ERP order and line-item tables
  identity: the dashboard's own account   # never svc-integracion
origin: the direct read predates the registry; start date unknown
reason: the orders data product hasn't published its contract yet
accepted_risk: >
  a change to the ERP tables can break the dashboard without warning;
  margin is still calculated outside Finance
sponsor: commercial-leadership
responsible: commercial dashboard team
registered: 2026-10-01           # illustrative dates
expires: 2027-03-15              # well clear of close week
exit_plan:
  - consume the orders data product once its contract is published
  - take margin from Finance's definition
  - close the direct-read permission on the ERP database
advance_notice: to the sponsor, before the expiry date
on_expiry: revoke access unless a signed renewal exists
renewals: 0                      # every renewal is counted and visible

Without the expiry date, an exception is a new rule nobody approved; with it, the permission becomes a commitment with an end. The sponsor is someone with authority who answers for the accepted risk, and who has to sign if the date arrives before the exit plan does. The renewal counter makes visible what is invisible at Northstar today. An exception renewed once can be prudent. One renewed every cycle is urban debt with its paperwork in order.

A registry that depends on someone remembering to check it won’t do much. The expiry rule can be made executable, the same way fitness functions (in Spanish) turn an architecture rule into a test. A scheduled check compares the registry against actual permissions and fails when an expired exception still has access to the ERP database. I learned late to look for exceptions in my own platform work, precisely because they show up in no diagram and no backlog.

A forgotten exception ends up looking a lot like a settlement from the informal settlement map; the difference is that the exception was signed once. So when the date arrives, I apply to exceptions the same four responses the framework proposes for settlements (recognition, integration, relocation or retirement). Renewing an exception recognizes it for another period, and closing it with the exit plan completed integrates it into the formal route. Applying those responses to exceptions is my extension.

The Grupo Diveco case

Portal Diveco, the Grupo Diveco platform I sketched in the first article, documents its debt case by case. In April 2026 the portal’s GraphQL schema hit its resource limit, and since then every new route has to use an alternate pattern. Two row-level filtering engines ran in parallel and diverged until they were unified in July 2026. An earlier manual tagging scheme degraded. Seen through the five sources above, the schema limit is saturated shared infrastructure and the two engines are a duplicated capability, two debts that live between buildings. Type checking is still disabled “temporarily”, a word the exception registry would turn into a date.

Renewal came in pieces too. In May 2026 the Brújula Comercial email left the legacy pipeline and started being calculated on the data lake, after a review found figures that didn’t match the portal. The Explosión de Materiales (bill of materials) module was rebuilt from scratch after a vendor’s failed migration, full replacement at the scale of one building. In August 2026 a tagging taxonomy for cloud resources arrived with an audit of resources that had no owner, the equivalent of starting with abandoned properties.

What doesn’t exist is an aggregate metric. Each case lives in its own document, the debt isn’t added up or tracked over time, and I can’t say whether the platform’s urban debt is growing or shrinking. The platform’s 3D model doesn’t tell me either. In it, SAP is a single monolithic building the size of a district, with RPA robots carrying boxes toward it, a good picture of what the table above calls a legacy installation. But the model is synced by hand and draws the monolith without measuring it.

How it would differ from technical debt

The difference between urban debt and technical debt has to be measurable, or the term is redundant. The framework asks every construct to explain something no other construct captures, and its second discriminant test applies this explicitly to the density of informal settlements, which must separate empirically from conventional technical debt inventories. I extend the same demand to urban debt, and that extension is mine. What I’d expect to observe is that two organizations with similar technical debt inventories differ in cost of change or in incidents depending on how much urban debt they carry, measured with countable things such as expired exceptions, ownerless buildings or capabilities with more than one implementation. If those measures move with the technical debt inventory above accepted thresholds, urban debt is the same debt under a new name.

All of this is a hypothesis. I haven’t measured it, and the preprint where I proposed the framework doesn’t either.

Attribution is another problem. If Northstar renewed by blocks and its changes got faster, the credit could just as well go to a bigger platform budget, one of the rival explanations I go through in how I would know this theory is wrong.

The cost of renewing in parts

Renewal by blocks has a price, and the diagram puts it in plain view. Wherever old and new coexist, Northstar maintains two routes to the same orders, two sets of permissions and two margins that someone has to reconcile while the change lasts. The ERP owner, the dashboard team, Finance and the data team have to coordinate in every block. The framework acknowledges this tension in governed mobility (data, commands and events traveling over contracted routes), which increases the capacity for change and imposes coordination costs, and renewal by blocks multiplies it, because every block is a new round of coordination.

That cost is why full replacement comes back at every steering committee. A single project is easier to explain than a sequence of blocks, and it has an end date you can announce. My objection is about path dependence more than principle. If the old city keeps accumulating dependencies while the new one is built, there’s more to migrate on cutover day than on approval day.

The exception registry costs something too. If requesting an exception takes several signatures and weeks of waiting, teams stop requesting them and build on the side. Formalizing informal settlements carries the same tension, because it improves governance and can suppress local experimentation. Automatic revocation carries its own risk. Cutting the commercial dashboard’s access on its expiry date, in the middle of close week, leaves leadership without its dashboard at the worst possible moment, which is why the example gives notice in advance and sets the expiry date away from the close.

The minimum registry

If there’s only capacity for one practice, I’d pick the exception registry with expiry dates, because it turns the least visible of the five sources into a list with names and dates. Starting it only takes listing the deviations that already exist, including the ones nobody ever called an exception (at Northstar, the two agents’ inherited credentials and the BI tool’s direct read), and giving each a sponsor and an expiry date even when nobody knows when it began.

The first review will probably turn up a case the template doesn’t cover, the exception whose sponsor has left the company. I’d treat it with the same rule as a dashboard with no owner. It’s abandoned property, this time in governance, and it gets retired unless someone claims it by name before the date.

This article is part of the Digital urbanization series, based on the preprint Toward a Theory of Digital-World Urbanization (Rodas López, 2026), a conceptual framework whose ideas I applied and refined on Grupo Diveco’s corporate platform, though its six propositions have not yet been empirically validated. Previous: AI agent governance: civic identity and jurisdiction. Next: The digital urbanization canvas: 10 diagnostic questions.