The digital urbanization canvas: 10 diagnostic questions

The digital urbanization canvas is a one-page set of ten questions for running an enterprise architecture assessment of a whole digital territory at once. Seven questions walk through the framework’s systems (territory, districts, buildings, public infrastructure, mobility, subsurface and inhabitants), and three look at what those systems produce together: digital habitability, informal settlements and urban debt.

It comes from Appendix A of my preprint on Digital-World Urbanization (DWU), and it’s a practitioner artifact I refined by using it in my own enterprise platform architecture work. This is the second-to-last post in the digital urbanization series. It pulls onto one page what the earlier posts develop separately, fills it in with Northstar Consumer Group, the fictional company that runs through the series, and proposes a way to find out whether the canvas does more than organize a conversation.

What the canvas is for

I use it to get the people who usually assess applications, data, platforms and agents separately into the same room, and to make every answer come from something another person can check later.

An application inventory, a capability map or an AI risk checklist each covers one or two of the ten questions, and none has anywhere to record that one depends on another. When a decision touches several systems at once, such as putting an agent into production, those dependencies are what set the order of the work.

The design of individual buildings, meaning each application or service, stays off the page, as it did in the francophone tradition of information-system urbanization, where the urbanist didn’t design buildings and dealt with land use, shared infrastructure, boundaries, interfaces and rules for evolution. I covered that in the forgotten tradition of information-system urbanization.

The ten dimensions

The layout mirrors the framework’s relational logic. The territory (the enterprise’s strategy, jurisdictions, regulation and risk appetite) takes the full top band because it bounds everything else. Below it sit the districts, which are business capabilities with an owner, the buildings that deliver them (applications, products, services and models) and the inhabitants, whether people, systems or agents. The buildings depend on the next row. Public infrastructure is the shared identity, audit, observability and notification services, and mobility is the APIs, events, queues and contracts that carry data and commands. At the bottom is the subsurface, the data products, semantics and lineage that almost nobody sees and almost everything depends on.

The three bottom cells are a different kind of thing, which is why they sit apart with a dashed border. None of them gets built directly. Digital habitability is the degree to which the environment is usable, understandable, reliable, accessible and safe for the people and systems working in it. An informal digital settlement is a locally useful solution created outside shared architecture, governance, ownership or lifecycle controls. Urban debt is the structural cost left behind by fragmented infrastructure, duplicated capabilities, opaque flows, abandoned components and governance exceptions.

In DWU’s causal logic, habitability is an intermediate condition between design mechanisms and organizational outcomes, so grouping it with the other two is my call. I made it because in a workshop all three get diagnosed the same way, from the symptoms the seven systems leave behind.

The canvas filled in for Northstar

The first seven rows summarize the original Northstar assessment, plus the details I added for this series, and I filled in the last three from the same material. Each dimension links to the post where I develop it (the first three share one).

How to read it

Two rows say more than the rest. Row 8 is empty because the case contains not one source on whether people can work with what they have. The facilitator’s impression gets recorded separately and doesn’t fill the cell. The only thing pointing toward it sits in row 9. The framework reads the pricing spreadsheet and the field-visit app as signs of a need the formal city (the governed part of the environment) didn’t meet in time, and that counts as a hint of low habitability until someone measures it.

Row 10 filled up almost entirely with references to other cells. That could mean urban debt, as a canvas dimension, is an aggregate of the others and doesn’t need a cell of its own. It could also mean it has evidence of its own, such as open governance exceptions or change lead times, that nobody at Northstar has gathered. I don’t know which reading is right. In a real case I’d start by looking for those exceptions before arguing about whether the cell is redundant.

What shows up between the cells

Northstar’s purchasing agent, the one that prepares purchase orders and currently acts with credentials inherited from a developer, already showed up in the first post as an example of one change spreading decisions across the seven systems. Here I want to see what each of three instruments records when someone asks to put it into production.

The application inventory has a row for the agent, with owner, vendor and cost. A capability map would place it in the Supply chain district, under purchasing. An AI risk checklist asks about model quality, bias, hallucination, prompt injection, data leakage and unsafe actions. Those questions are necessary, and DWU treats them as still relevant; what it proposes is placing them within identity, jurisdiction, infrastructure and operational accountability.

On the canvas the agent sits in cell 7, and the question “do we promote it?” spreads across five others. The framework uses almost this exact example to explain why the seven systems are interdependent. Introducing an autonomous purchasing agent may require changes to territorial policy, district ownership, public identity services, data access, mobility contracts and observability.

For the agent, the order of the work comes out like this. Giving it its own identity (cell 7) assumes the identity service can issue and audit non-human identities (cell 4), and scoping its permissions by jurisdiction assumes you know which entity’s rules it operates under (cell 1) and who sponsors it (cell 2). The route its orders take to the ERP (cell 5) and the supplier data it reads (cell 6), the two dashed arrows in the diagram, come later, because their scope depends on what gets settled in cells 1 and 2. None of the three lists of findings, read on its own, produces that sequence. I cover the agent’s own profile in AI agent governance.

Filling it in with evidence

A canvas filled in from memory in a meeting room is a faithful portrait of what the people in the room believe. That portrait is a fine place to start, and it misleads once it’s presented as an assessment. My rule is that every entry cites a source another person can open (a registry, a log, an inventory, an ADR, a survey), and that anything asserted without a source gets recorded separately as a workshop hypothesis until someone confirms or discards it. It’s the same discipline as building evidence before consensus, applied to diagnosis.

The sources come from the framework itself. Each of its six propositions comes with a type of illustrative evidence, and the Northstar assessment proposes an intervention for each system that is often a record to create (jurisdiction tags, a building registry, a registry of actors with sponsors). I filled in the urban debt row with the evidence DWU plans to use for its first case study, such as ADRs, cycle-time measurements and incident logs. The third column is the one I use most in workshops, because it collects sentences that sound like findings and haven’t earned it yet.

Any of those sentences might be true. What the room can’t know is which ones, and whatever gets written in the cell ends up being the version defended at the architecture board.

In practice I record each cell as a small document, and the fields matter more than the format.

# Illustrative. One cell of the Northstar canvas; the format isn't a standard.
cell: 5-mobility
question: "How do data, commands, events, and approvals move?"
evidence:
  - source: integration inventory
    observation: several integrations authenticate with the shared account svc-integracion
  - source: logged connections to the ERP database
    observation: the BI tool and one country's application read ERP tables directly
workshop_hypotheses:
  - claim: "everything goes through the integration layer"
    status: contradicted by the second observation
depends_on:
  - cell: 7-inhabitants
    reason: "the shared account is an inhabitant; who sponsors it?"
  - cell: 6-subsurface
    reason: "is the country app's margin computed from that direct read?"
no_evidence_yet:
  - failure rates per integration
  - lead time for change
decision_it_informs: whether to promote the purchasing agent

The field that takes the most work is depends_on. It forces you to write down that a mobility finding can’t be fixed inside mobility, because the shared account is also an inhabitants problem and the direct read may be feeding one of the three margins. An integration inventory would record both observations and neither question.

Where the canvas fails

Decisions that don’t change

That the canvas leads to better decisions is, for now, my own hypothesis. It isn’t a validated instrument yet, nobody has tested it, and its formal evaluation is left for future work. If it’s useful, that should show in the decisions it produces more than in how complete it looks.

DWU lays out a four-stage validation path, and the second stage is the design-science development and evaluation of diagnostic artifacts like this one. For the canvas, that stage suggests comparing the decisions it produces against those produced with an application inventory, a capability map or an AI risk checklist.

I’d set up that comparison with one documented case, the same evidence package for everyone, and four groups of analysts, one per instrument. Each group would answer the same decision questions, for example whether to promote an agent and under what conditions, or which shared service to fund first. Then I’d compare the preconditions each group names outside the decision’s own area, and the order of work each one proposes.

If the canvas adds something, I’d expect its groups to name more preconditions in other dimensions and to propose a different sequence. Three results would count against it. The first is canvas decisions that look no different from the inventory group’s. The second is a difference that disappears once the other groups get the same time and the same mix of people, because then the improvement would come from the workshop. The third is two canvas groups, working from the same evidence, reaching incompatible decisions.

In a real organization, a study like this also depends on getting permission to use its evidence.

Two assessors, two canvases

The third adverse result is the most serious, because it rests on the inter-rater test the framework sets for itself, which I work through in the last post of the series. If two assessors can’t place the same things in the same cells, the canvas inherits that instability.

Northstar has obvious candidates for disagreement. The nightly script that reconciles orders is a mobility route and also an informal settlement. The svc-integracion account can be recorded as an inhabitant, as a gap in the public identity infrastructure, or as a symptom of mobility without contracts. The low-code field-visit app is a building to one assessor and a settlement to another.

In workshops I handle this by giving each item a home cell and references in the others. That’s enough to run the conversation.

For measurement it makes things worse, because two assessors can agree on the references and disagree on the home cell without the page showing it. If you use the canvas for research, I’d ask you to record those disagreements as data before resolving them.

When the canvas turns into paperwork

The framework’s ninth principle puts habitability above artifact completeness. A canvas is an artifact, and it can violate that principle as easily as a target-state diagram. All it takes is for an organization to require it at a project gate. From then on, someone fills it in the night before and the board approves it because it’s complete.

That canvas is easy to recognize. All ten cells are full, none is marked “no evidence”, and it ends without a decision or a date. To avoid producing one I hold myself to four rules. Each canvas answers a single, concrete decision. It ends with decisions that have an owner and a date. A cell without evidence stays empty and marked. And the canvas expires, because the territory keeps changing; at Northstar, one country adopting a shared notification service would be enough to make cell 4 out of date.

There’s a cost those rules don’t remove. Gathering evidence takes longer than filling in the page from memory, and in many organizations the evidence doesn’t exist yet, because nobody keeps an agent registry, an integration inventory or lineage. The risk is that the canvas becomes the excuse to build all those registries before deciding anything. When the canvas takes longer than the decision it was meant to inform, I’d rather decide with empty cells and write down which registry was missing.

Write down what doesn’t fit

The ten questions in the Northstar table can be used as they are. What I most want back from people who use them is whatever didn’t fit: an item that wanted two cells, a cell that stayed empty in every workshop, something that needed an eleventh cell written in by hand. DWU itself admits that its seven-system structure may be missing constructs, including one for power relations, and that some systems might merge. Those margin notes are the kind of evidence the last post in the series, how I would know this theory is wrong, needs.

In a workshop, that missing construct shows up fast. When someone with more authority in the room corrects everyone else’s answers, the canvas records their version as if it were everyone’s. That’s why I note next to each cell who filled it in, along with the evidence, so at least it’s visible whose answer each one is.

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: Urban debt and renewing the city without evicting it. Next: How I would know this theory is wrong.