Infrastructure.
Scope infrastructure assets and services.

Infrastructure would model the physical systems beneath the synthetic city — assets and networks connecting the same wards, households and businesses already represented throughout the City Twin™, and sitting between Land → / Construction → and service domains like Roads → .

None of that exists in the engine today. This page is a scoped, honest roadmap — not a live domain page — because the correct alternative was inventing asset counts, capacity figures and certification scores that don't exist. We chose not to.

Lagos City Twin™ · 1940–2026

The six capabilities below describe what an Infrastructure domain would need to cover to deliver the "open one place, see what supports it" experience this page's own signature section illustrates. None are active in the current release today; this page is roadmap scope rather than an design specification.

Individual modeled infrastructure assets and facilities — would need its own dedicated table, not a repurposed generic row from an unrelated domain.

How physical systems connect areas of the city — a genuine network/graph concept, not modeled anywhere today.

Infrastructure tied to modeled city geography — would extend the shared city geography layer used across domains.

Service or design capacity where represented — no evidence review of real capacity benchmarks has been performed yet.

Asset condition, status or lifecycle characteristics — no condition vocabulary or generation logic has been designed.

Construction, activation, operation, upgrade and retirement — would need a direct relationship into Construction's already-real Project/Permit lifecycle, which doesn't exist today.

Synthetic by design, once built: FCTE would contain no real municipal asset inventories, engineering survey data or live network conditions — only an analytical representation of a plausible physical-infrastructure layer, calibrated against real benchmarks where evidence exists.

Infrastructure would provide the shared physical layer. Specialized domains such as Roads, Energy and Water would model their own systems in greater depth. That distinction matters — see the boundary section below.

No field list, no integrity rule, no stable identity strategy has been decided for any of the above — naming them here is scope-setting, not a data structure announcement.

No live result is shown because this domain is not yet published as a generated release. Compare this to the published semantic query on Construction → or Vehicles → , both of which show release-backed data.

Possible connections for scoping a future release. No implemented record links are asserted.

This is the experience Infrastructure would deliver once real — shown here as a labeled wireframe, not a real ward, asset, or count. No ward numbered below exists as an infrastructure record; no figure below is a live value.

Citizens, Households and Businesses per ward are real, live figures elsewhere in this catalog (see Households → and Business → ). Every spoke below the Infrastructure layer is not yet a real, queryable domain:

The people and economy layer above resolves to real FCTE domains; the infrastructure layer below it does not, yet. That's the honest shape of this page: a real city of citizens, households and businesses, waiting on a physical layer that hasn't been built.

This distinction needs to be crystal clear before any of Infrastructure is built: it prevents a future data structure from silently duplicating what the real Construction domain, or a real service domain like Transport, already does.

Construction models creation. Infrastructure would model the asset. Service domains would model what that asset enables. Today, Construction's own "Infrastructure" ProjectType category (Road Construction, Water Treatment Plant, Power Substation — all real rows) covers the FIRST of these three questions only: that a project to build something happened. It does not answer the second question (what physical asset exists, where, with what capacity and condition) or the third (what ongoing service that asset provides) — those remain open, exactly the gap this roadmap describes.

• Project, ProjectPhase
• Permit → Inspection → Completion (Lagos)
• 16/16 structural + 5/5 realism checks, Lagos

• Asset, Location, Capacity
• Condition, Lifecycle
• Not designed

• Roads (planned)
• Energy (real, deployed — power grid Lagos, plus a Lagos-only utility-connection data structure)
• Water (real, deployed — treatment-to-billing workflow, Lagos)
• Telecom, Waste (not built)
• Transport (real, deployed — closest existing service domain)

Unlike every published domain in this catalog, Infrastructure has no data structure at all, so there is no realism angle, no structural check, and no live asset count to report — not "not yet written," but "nothing exists to write a check against."

The two nearest real signals found this session are both labels, not assets: Construction's own "Infrastructure" ProjectType category (Road Construction, Water Treatment Plant, Power Substation, Drainage Channel — real, certified project rows) and Finance's "Infrastructure & Public Works Directorate" (a real government budget/org unit). Neither carries a physical asset's location, capacity or condition — they record that a project happened or that a directorate exists, not what physical thing resulted.

Every other domain page in this catalog reports either a real certification count or, at minimum, a real generated table with a disclosed absence of certification (as Vehicles does). Infrastructure cannot honestly claim even that — no generated release exists yet to certify.

There is no release history for an Infrastructure domain anywhere in the engine, because no Infrastructure work has been started.

This is the single limitation underlying every section above. Nothing on this page should be read as describing current engine behavior — it describes a scoped, honest roadmap.

Even once built, a real Infrastructure domain would not claim hydraulic, electrical or structural engineering simulation merely because it models infrastructure assets — nor would it model outages, service interruptions or dynamic network reliability unless explicitly scoped in later.

Construction's real ProjectType rows (e.g. "Road Construction," "Water Treatment Plant") certify that a government infrastructure project happened — they do not represent a physical asset's ongoing location, capacity, condition or lifecycle after completion.

Roads has its own honest roadmap page (see Roads → ); Telecom and Waste have no page or data structure at all yet. Energy → and Water → are both real and deployed already, in Lagos, independent of whether this Infrastructure domain itself is ever built.

Infrastructure has not yet completed an evidence-first review against Nigeria infrastructure-agency and utility publications and municipal asset registers. Any future production data structure should be benchmarked against those sources before completeness or realism is claimed.

Back to Domain Directory →

Parcels, zoning and ownership — real, deployed.

Projects and permits are built — real, deployed, certified.

Asset, Location, Capacity, Condition, Lifecycle — the missing physical layer this page scopes but does not build.

Roads (planned); Energy, Water, Telecom, Waste (not started); Transport real today.

Households and Businesses already live and operate within this real synthetic city.

A conventional synthetic-infrastructure product can generate millions of realistic-looking assets with no context behind them. FCTE's argument, once Infrastructure is real, would be that every asset sits in a ward that already has real citizens, households and businesses elsewhere in the same synthetic city — that connective tissue is the differentiator, and it's exactly why this page refused to fabricate the asset counts to make that case prematurely.

Land → Construction → Infrastructure → Service → City Life — one physical city, connected to every synthetic life built on top of it, once Infrastructure exists to complete it.

Available as Standalone Domain · Multi-Domain Bundle · Full City Twin™