In Digital-World Urbanization (DWU), digital habitability is the degree to which an enterprise digital environment is usable, understandable, reliable, accessible and safe enough for the people in it to work under rules they understand. Architecture diagrams don’t record it, so an environment can look technically coherent on them and still be uninhabitable in use.
A planning analyst in country B at Northstar Consumer Group, the fictional company I use as the case throughout this series, needs last month’s closed margin for a pricing review. Her access request for the margin data product has now been open longer than the analysis itself would take. What her environment lacks is habitability.
The previous post in the series proposed mapping shadow IT as informal settlement. This one deals with the condition that, according to the framework, makes those settlements grow.
The path to the margin
The task looks simple. The number she wants already exists, three times over in fact. To reach one she can use, she has to answer four questions in order, and at each one the environment offers her a shortcut that’s faster than the formal path.
First, where it is. Northstar calculates margin three ways (Finance’s figure at close, the commercial dashboard’s and the one in a country application), and none of them sits in a catalog she can search. What does reach her without searching is the adjusted-price spreadsheet that circulates by email. It has prices, and with a column added by hand it yields something that looks like a margin.
Second, who approves. Margin belongs to what DWU calls the subsurface, meaning the data, semantics and lineage that applications depend on. Its district, the business capability that ought to own it (Finance, here), requires approval for the closing product and hasn’t published who grants it or how long it takes. The request lands in a generic queue. While she waits, a colleague shows her that the BI tool reads the ERP tables directly and that she can build the number from there without anyone’s permission.
Third, what it means. If she gets access, she’ll have to decide which of the three margins her review needs, and none comes with a published definition explaining how it differs from the others. Her colleagues handle that with an unsanctioned AI assistant. They paste in the columns and ask what they mean. The assistant always answers, and it sounds just as sure when it blends two definitions as when it gets things right.
Last, what happens when it breaks. If her figure doesn’t reconcile with the one Finance presented at close, she has no product status to check and no channel to report it. The gap gets closed by manual reconciliation, done by someone who designed none of the three sources.
Underneath runs a fifth question, who is responsible, and on this path it has no answer at any step.
None of that path shows up in Northstar’s architecture artifacts. The capability map shows the Finance district with its margin product, and the data platform diagram shows the product as published. Anyone reviewing those documents will find them complete, and they’ll be right.
Coherent on the diagram, uninhabitable in use
DWU states this gap between document and use as its ninth principle, habitability over artifact completeness. Under that principle, architectural success includes usability, safety, clarity and adoption as well as diagrams and standards. A technically coherent environment can be hard to inhabit if its inhabitants (the people, systems and agents working in it) can’t discover services, understand data, obtain access, recover from errors or know who is responsible.
Habitability connects architecture to conversations that usually happen in another room. Among development teams that conversation is called developer experience, and in the rest of the company, employee experience. The sociotechnical tradition already explained many implementation failures through misalignment between structures, roles, incentives, practices and technical design (Bostrom & Heinen, 1977a, 1977b). DWU changes the scale of the question. It stops asking whether a system fits a practice and asks whether the whole environment, with all its buildings (the applications, products, services and models that deliver capabilities), offers navigable routes and understandable rules to whoever has to move between them.
For the analyst, the BI tool is probably the best software in her day. Ask her how satisfied she is with it and she’d say very. The steps where she left the path don’t belong to any building, and a survey about a building won’t see them.
DWU’s list for measuring a platform team, which I quoted in infrastructure before density, ends with habitability.
A loop that feeds itself
The framework proposes a reciprocal relationship. Low habitability encourages informal digital settlements, locally useful solutions built outside shared architecture, governance, ownership or lifecycle controls, because the formal city (whatever is official and governed) doesn’t meet the need at an acceptable speed. And widespread settlements can lower habitability further. The previous post drew that reciprocity between two nodes. Here I add a step in between, taken from P5, the proposition that associates settlement density with duplicated data, hidden dependencies, control gaps and operational rework.
If the analyst forwarded the spreadsheet with her margin column, Northstar would have a fourth calculation in circulation, with no owner. The BI query over the ERP tables adds a hidden dependency, and the day one of those tables changes, the number will break without warning. Each answer from the assistant is one more definition, unrecorded. That sediment is what DWU calls urban debt, the constraints accumulated from fragmented infrastructure, duplicated capabilities, opaque flows and governance exceptions.
As I read it, the debt closes the loop. The next analyst looking for the margin would find four candidates, more undocumented direct queries and contradictory answers from the assistant, and each step would cost her more than it cost her colleague.
Making the formal path walkable
The order of the numbers on the loop has practical consequences. Removing the spreadsheet or blocking direct ERP queries (points 2 and 3 without 1) takes away the exit the analyst was using without giving her a path, and she’ll most likely take the next shortcut on the first diagram. That’s why I’d expect the four responses from the previous post (recognition, integration, relocation or retirement) to pay off more once the formal path already competes with the shortcut. Consolidating the three formulas into one definition, the subject of governing the data subsurface, runs into the same limit. A single definition nobody knows how to request access to pushes people back to the spreadsheet.
Point 1, making the formal path walkable, is the one that, as I read it, can reverse the loop, and also the least visible. On the access step, one example is the response the catalog could give the analyst when she requests the product before she has permission. Neither the field names nor the shape come from any standard.
{
"status": "access_pending",
"resource": "data-product/closing-margin",
"owning_district": "finance",
"approver": "role: owner of the closing margin product",
"request": {
"purpose": "pricing review",
"jurisdiction": "country-b"
},
"published_turnaround": "<agreed by the district and visible to the requester>",
"meanwhile": "aggregated view of the closing margin, available without approval",
"definition": "Finance's margin at close; differs from the commercial dashboard and the country app calculation",
"product_status": "<link to open incidents and last load>",
"contact_if_broken": "product channel, staffed by the district"
}published_turnaround turns an opaque wait into a promise someone can check, and meanwhile gives the analyst a legitimate route while permission arrives, which is what the BI tool was offering her from outside.
The Grupo Diveco case
In Portal Diveco, whose story opens this series, the employee civil registry was designed together with the process owners. That registry is REDI, also known as the “Consulado Diveco,” and the portal’s innovation report sums up the decision in one line, “when someone feels the tool was made for them, adoption is not a problem.” The Explosión de Materiales module (bill of materials explosion) is “100% self-managed by the end user,” so whoever uses it doesn’t depend on another team to run it.
Two more decisions have to do with understanding. The Business School, running since June 2026, certifies that people can read the Brújula Comercial. I told how it started in how I made them trust our data, and I come back to it below as an incentive. The spec for unified row-level filtering asks for an “honest interface.” I read that as a habitability criterion, because the screen has to show the restrictions that are actually enforced.
The platform’s 3D model tells you what exists, but as a discoverability tool it has a clear ceiling. Its data is static configuration synced by hand, and its buildings don’t link to the tools they stand for, so reaching any of them still means going to the portal.
What’s missing is the instrument. The platform has nothing that measures habitability, no surveys, no task-completion tests, no record of support load and no count of parallel tools (the four candidate indicators below). The line from the innovation report is the intuition the framework states as P6, and without those indicators none of this tests it.
P6 and the test that could sink it
The framework’s proposition for this construct is P6, which says that greater habitability will be associated with greater adoption of governed platforms and less reliance on unofficial parallel tools. It’s a hypothesis the preprint states without data to back it yet, and a case like Northstar’s can only show what testing it would involve.
If P6 holds, what I’d expect to see at Northstar has two halves that should move together. As the path to the margin becomes walkable, requests through the formal channel and use of the closing product should grow. At the same time, three things should fall: circulation of the spreadsheet with margin columns, BI queries computing margin over ERP tables, and definition questions that end up with the unsanctioned assistant.
Beyond the rival explanations that apply to the whole framework, habitability faces a test of its own, which I consider the construct’s most demanding. It should correlate only moderately with generic user-satisfaction or technology-acceptance instruments. If it converged with them above accepted thresholds, it would be redundant, and the framework would be putting an urban name on something already measured.
The analyst who is happy with her BI tool is exactly the case that test needs. A habitability instrument that gives her the same score as a satisfaction survey is measuring the tool. If that happened systematically, I’d have to narrow or abandon the construct, and that kind of condition is the subject of the last post in the series, how I would know this theory is wrong.
How to measure without fooling yourself
Four kinds of evidence are suggested for testing P6. I present them as candidate indicators, with no reference values, because none is validated as a measure of habitability and each can mislead in its own way.
| Candidate indicator | What it might capture | How it can mislead |
|---|---|---|
| Inhabitant surveys | perceived clarity, trust, ease of getting access | drifts toward satisfaction with a single tool; only those who stayed answer |
| Task completion | whether someone finishes a real task through the formal path | a poorly chosen task measures one building and misses the stretches between buildings |
| Support load | the steps where people get stuck | can drop because people stopped asking for help and went to the spreadsheet |
| Use of unofficial tools | demand the formal city doesn’t meet | you only see what you’ve mapped, and banning hides more than it reduces |
The table leaves me with two immediate design decisions. The first is that the completion task has to cover the whole path, and at Northstar it would be phrased in the analyst’s own terms, “get the closing margin for country B for the last closed month, without asking a colleague for help, knowing which definition it uses.” What gets recorded is whether she finished, which steps she went through and how many times she left the formal path.
The second is to run a generic satisfaction instrument alongside the habitability one, to check that the correlation stays moderate. It’s the same discriminant test, brought down to the scale of a single company.
Adoption without habitability
The tension attached to P6 is the one I take most seriously. Habitability can raise adoption, yet mandatory use, incentives and power relations can produce similar results. At Northstar that would look like healthy platform adoption figures for the margin product, with the same four-step path the analyst walked.
Mandate is the simplest case. Suppose Finance decrees that only the closing margin counts in pricing reviews. Use of the governed product goes up. The spreadsheet keeps circulating, now for the questions the closing product can’t answer in time, and the analyst brings two numbers to the meeting, the official one for the slides and the spreadsheet one for the decision. The first half of P6 holds and the second doesn’t even move.
Incentives I know firsthand. In how I made them trust our data I described how an institutional email and a demo produced a spike in opens for a data tool, then a flat line. What changed the curve was a course with an exam and a certificate people could post, with rules enforced server-side that I covered in the post on adoption engineering. Read through this framework, that’s a status incentive. The adoption it produced was real, and it says little about how habitable the rest of the environment was. Had I measured habitability with usage figures from that period, I’d have credited the environment with what the certificate did.
In both cases the signal sits in the second half of P6, which is why the two halves are read together. If use of the governed product rises while use of the spreadsheet and the direct queries doesn’t fall, I suspect a mandate or an incentive before I suspect better habitability.
A district manager gets access to the closing product with a direct message while the country B analyst waits in the generic queue. That’s power relations at work, and they’re the hardest mechanism to see, because the environment is the same for both of them and the habitability each one experiences isn’t. An adoption figure dominated by people who can skip the queue looks a lot like the figure for a habitable environment.
That’s why results are split by type of inhabitant. A single number blends the country B analyst with the district manager, and the two of them don’t live in the same environment.
Making the path habitable costs something too. Publishing an approver and a turnaround obliges the district to meet them, with people assigned to a queue nobody used to staff. A readable definition has to be maintained every time the formula changes. And the “meanwhile” view is one more building, with its own owner and lifecycle, which turns into the fourth margin in the example if nobody looks after it.
Which step to fix first
There’s one limit I don’t know how to solve. The cleanest test for separating habitability from mandate would be to withdraw the mandate and watch who keeps using the platform, and no organization will do that just to check P6.
What Northstar can do tomorrow is more modest. Ask someone in country B to reach the closing margin without asking anyone, and count the informal exits they take. A count like that doesn’t test P6, which would need many organizations and a validated instrument, but it tells the Finance district which of the four steps to fix first.
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: Shadow IT as informal settlement: map it first. Next: AI agent governance: civic identity and jurisdiction.