In an executive meeting at Northstar Consumer Group, a fictional manufacturer and retailer I carry through this series, someone asks what last quarter’s margin was and gets three answers. Governing the data subsurface means giving that question a single definition with an owner, lineage, quality rules and an access policy, and connecting every application that answers it to that definition through controlled routes. In the Digital-World Urbanization (DWU) framework I propose, the subsurface is the set of data and knowledge systems that visible applications depend on.
Finance brings the figure from its close, the commercial dashboard shows another, and one country’s application shows a third. Nobody in the room is lying. Each figure is correct under the rule used to compute it, and none of those rules is written down anywhere the other two can look it up.
Why Northstar has three margins
Each figure was built for a legitimate purpose with whatever data was at hand. For the example, I assume the following.
Finance computes margin at close, with credit notes applied and cost already adjusted. Its figure is the most reliable and also the last to arrive. The commercial dashboard was built to watch the month as it happens; the BI tool behind it queries ERP tables directly, using the formula someone on the commercial team wrote when they built it. The country application also reads ERP tables and adds a cost component that only exists in that jurisdiction. That’s three purposes and three formulas, none of them recorded in a shared place.
What that scene describes is a subsurface nobody built on purpose. Northstar’s data is whatever its applications leave behind, the exhaust they produce while running, and every team that needs an answer drills down on its own until it hits a table that works.
Leavell (2026) uses the term interpretive debt for interpretive commitments that accumulate in layers and constrain change. The three formulas are exactly that. Each one holds up reports, habits and decisions, and unifying them later means explaining to every audience why their historical number moves.
The BI tool’s direct query against ERP tables is also one of the improvised roads I described in the post on point-to-point integrations. It enters the subsurface wherever it can, with no contract, and the owner of the record has no idea anyone depends on that column.
I went through a real version of this scene, at a different scale, in the project I described in La Brújula Comercial y el número único (in Spanish). When Finance and Commercial show up with different figures, the meeting stops discussing the business and starts discussing where the numbers came from.
The subsurface as civic infrastructure
That set includes operational records, analytical data products, metadata, lineage, quality controls, semantic models, vector indexes, knowledge bases and the context handed to models. The applications and dashboards that rest on it are the buildings, and the people, services and agents that consume it are the inhabitants. Of the twelve posts in the series, this is the one closest to what usually goes by the name data governance.
Two properties
The framework attributes two properties to the subsurface, and both show up in Northstar’s meeting.
The first is that its failures spread to buildings that seem unrelated. A cost table loaded with bad data shows up at once in the commercial dashboard, in the country application and in any agent that received that data as context. Each team investigates it separately, because none of them can see the shared dependency.
The second is that using it responsibly takes four things no application provides by itself. It needs a map of what exists and where it comes from, maintenance, an owner and controlled connections.
The urban analogy is a city’s water, power and telecommunications, invisible to almost everyone who lives there and indispensable to every building. People notice them when they fail, and at that point the only useful question is who owns the pipe.
The diagram shows the state Northstar would like to reach, with a single margin definition that buildings and agents depend on. That state has a cost I come back to below, because centralizing the definition also centralizes the failure.
The civic infrastructure principle
The fifth of the framework’s ten principles is called data as civic infrastructure. It states that data, semantics, lineage and knowledge require explicit ownership, service levels and access policies. Civic infrastructure is DWU’s name for the shared services an organization treats as a common base instead of rebuilding them in every project, and the principle asks that a definition like margin get that treatment. Under that principle, data stops being the ownerless exhaust of applications.
What it inherits from data mesh
Almost all of this is already in data mesh. Dehghani (2020) proposed domain-oriented data ownership, data as a product, self-service data infrastructure and federated computational governance. DWU inherits those four ideas and doesn’t set out to replace data mesh.
What the framework adds is the connection between the subsurface and the rest of the city. Data mesh describes who owns a data product. DWU also asks how that product connects to the district’s authority, to mobility routes (the APIs, events, queues and contracts that data and commands travel through) and to the inhabitants that consume it, agents included. A district, in DWU, is a business capability or domain with an owner, and Northstar has four (Commercial, Supply chain, Finance and People).
| Question about margin | Data mesh | DWU |
|---|---|---|
| Who decides what it means? | The domain that produces it | The Finance district, with decision rights documented against the other districts |
| How does it reach the dashboard? | Through the product’s interface; the consuming building is outside its focus | Through a route with a contract; direct queries against ERP tables are a route to retire |
| Who can read it? | The product’s access policy | A policy per jurisdiction and per inhabitant, agents included |
A well-run catalog would say margin belongs to Finance, but it wouldn’t see the BI tool’s direct query, because that query never went through it. For DWU, that query is part of the same problem.
Declaring margin at Northstar
Applied to Northstar, principle 5 produces a declaration along these lines.
# Illustrative. One possible way to declare the metric; it follows no standard.
metric: gross_margin
version: 3
owner_district: finance
steward: cost accounting
definition: >
Net sales for the period minus cost of sales,
by legal entity, product line and month.
formula: net_sales - cost_of_sales
percentage: gross_margin / net_sales
sources:
- product: finance.net_sales
- product: supply_chain.cost_of_sales # another district, explicit interface
lineage:
source_records: [erp.billing, erp.credit_notes, erp.costs]
registered_in: corporate_catalog
states: [preliminary, final]
quality:
- rule: net_sales present for every entity and month
- rule: cost_of_sales available before the month is published
- rule: margin reconciled against the general ledger at close
on_failure: publish as preliminary and notify consumers
service_level:
preliminary: daily refresh during the month
final: at each entity's accounting close
access:
jurisdiction: each legal entity sees its own data; the consolidated view is regional
people: [finance_district, commercial_district]
agents: only with a civic profile and a registered sponsor
variants:
- metric: local_margin
derived_from: gross_margin
difference: adds a cost that only exists in one jurisdiction
owner_district: commercial
jurisdiction: legal entity of one country
consumers: [country_app]
consumers: [finance_close, commercial_dashboard, purchasing_knowledge_base]The file forces four decisions.
Who can change the meaning
Assigning margin to the Finance district means any change to the formula goes through that district and gets versioned. Finance still doesn’t build dashboards, but it’s the only district that can change what margin means.
Where each piece comes from
Cost of sales comes from a Supply chain data product. Finance’s margin therefore depends on another district’s asset, and lineage puts that dependency in writing. If Supply chain changes how it calculates cost, the catalog knows which metrics and which buildings are affected before someone discovers it in an executive meeting.
When I wrote about the serverless lakehouse on DuckDB (in Spanish), the decision I was most careful about was keeping the derived layer from ever being mistaken for the source of truth. The lineage block records that same distinction, this time declared for anyone who looks.
A quality rule that warns
When reconciliation against the general ledger fails, the metric is published as preliminary and consumers get notified. That rule, together with the metric’s two states, removes much of the conflict in the example, because at Northstar the gap between Finance’s figure and the commercial dashboard’s is mostly about timing. Commercial wants to see the month as it happens. Finance wants a final number. With one definition and two states, the dashboard can show the current month without writing a formula of its own.
The variant with its own name
The country application had a reason to add its local cost, and erasing that difference in the name of a single number would destroy information that jurisdiction needs. The variant keeps the rule, gives it a different name, declares which metric it derives from and how it differs, and assigns it an owner. Leadership may still see two figures in the same meeting, but each arrives with its name, its owner and a declared difference from the other.
When the subsurface feeds actions
As long as the subsurface’s consumers were people reading reports, a wrong definition produced a bad meeting. With agents, vector indexes and knowledge bases, the subsurface becomes a direct input to action.
Among Northstar’s twelve experimental agents is a purchasing agent that prepares purchase orders and currently runs on credentials inherited from a developer. Suppose that, to prioritize suppliers, it retrieves from a knowledge base an internal policy that sets minimum margins by product line and compares it with gross_margin. If that knowledge base indexed an old version of the policy, or documents from a legal entity with different rules, the agent prepares orders on the wrong criterion, and no person reviews the figure before it’s used.
It also repeats the comparison for every supplier and every product line. Controls designed for human readers, such as an analyst who checks a figure against last month’s before using it, have nowhere to act in that loop.
That’s why vector indexes and knowledge bases fall under the same regime as margin. They need an owner and lineage (which documents, in which version, were indexed and when). They also need quality rules for when a source document is withdrawn, and an access policy that honors the original document’s. An index that mixes documents from Northstar’s five legal entities without their jurisdiction tags moves information from one entity to another even though nobody decided it should.
The access section of the YAML anticipates this with a line for agents, which can only consume the metric if they have a civic profile and a registered sponsor. What a civic profile is, and why an agent with inherited credentials doesn’t have one, is the subject of the post on AI agent governance.
The Grupo Diveco case
Among the things beneath the modules of Portal Diveco, the platform described in the first article, is a data lake that has had its own repository since May 13, 2026. It’s organized into Bronze, Silver and Gold layers (the so-called medallion architecture) on Parquet and DuckDB.
The piece closest to Northstar’s YAML is the lake’s shared semantic layer. It’s the single source of filters and of definitions such as net sales, margin and estimate versus actual, and its documentation describes it as a common core that must not be redefined per report. Among the findings the portal documents are inconsistent definitions of net sales and margin across layers and across BI tools. That’s the real counterpart of Northstar’s three margins, this time with nothing assumed.
Around the lake there are monthly reconciliation documents, runbooks and knowledge bases for the agents. In the platform’s 3D model, District 4 shows that path, from mines that stand for the sources to a data factory and three warehouses, Bronze, Silver and Gold.
What’s missing is the equivalent of the sections in Northstar’s YAML that assign an owner, lineage and quality rules. The lake doesn’t expose that information per data product, and lineage is written down only for a few specific cases. The model inherits the same gap, because it shows where data flows and says nothing about who owns each warehouse.
What the case shows is that the idea can be run in a real company. It doesn’t measure whether it reduces manual reconciliations or duplicated datasets, which is what the hypothesis in the next section would require.
What I’d expect to observe
If principle 5 holds, a company that assigns owners, lineage and quality rules to its critical definitions should show fewer manual reconciliations between areas and fewer duplicated datasets computing the same thing. The framework ties that evidence to its proposition P5, on informal settlements and urban debt.
That’s a hypothesis with no empirical validation yet. Stronger executive sponsorship, one of the rival explanations the framework itself lists, could produce the same improvement on its own, and any study that tried to test the principle would have to separate one effect from the other.
Power, bottlenecks and a single point of failure
The YAML above takes an afternoon to write. The expensive part is agreeing that the commercial dashboard’s figure is now called preliminary margin, and that the country application’s historical number is a variant with a different name. Every area comes to that conversation defending the figure it has been evaluated on.
Each time I’ve been through that conversation in platform work, it turned into a negotiation over power, because deciding what a number means when others are evaluated on it is a form of authority. Among its limitations, the preprint acknowledges that power relations may be a construct the framework is missing. Principle 5 says a definition needs an owner, but it doesn’t say how that ownership gets negotiated between areas with unequal power.
The second cost is more serious. Assigning every definition to an owner can turn the Finance district into a checkpoint that every new analysis has to clear. The framework’s seventh principle, subsidiarity with federation, asks for decisions at the lowest competent domain level, and a badly run semantic catalog does the opposite. If every local variant needed approval from a corporate committee, what I’d expect to see is countries that stop declaring their variants and go back to computing on their own, this time outside the catalog. Formalization would have created the informal settlement it meant to prevent.
The third is in the first diagram. A shared definition reduces duplication and concentrates failure. If version 4 of gross_margin ships with an error, every building and agent that consumes it inherits the error at the same moment. DWU records this tension for all shared infrastructure (less duplication in exchange for bottlenecks and concentration risk) and leaves it unresolved; it proposes treating it as a moderator to be measured.
There’s also a limit the YAML doesn’t touch. A correct definition doesn’t guarantee that people use it. In how I made them trust our data I described how closing a data unit’s credibility gap was a problem of trust and status, and a semantic catalog solves neither.
Start with the owner
Of everything in the YAML, the owner_district line is where I’d start. Before the catalog and before any lineage tool, someone has to be able to say “this definition is mine, I maintain it and I answer for it when it fails.” Try it on the most disputed metric in your organization by asking who could change its formula tomorrow. If the answer is “nobody,” “whoever built the report” or silence, that’s where data governance starts.
One decision at Northstar is still open, and the YAML doesn’t make it. The country variant can stay as a recognized variant, be integrated into the corporate definition if its local cost turns out to matter across the region, or be retired. Those are three of the four responses the framework proposes for informal settlements, and the next post covers when each one fits.
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: Point-to-point integrations are improvised roads. Next: Shadow IT as informal settlement: map it first.