Buildings are Designed as Spaces. Software Must Model Them as Systems.

A floor plan is an extraordinarily efficient abstraction.

It can describe thousands of square metres through lines, dimensions, boundaries and labels. It tells us where one space ends and another begins, how areas relate physically and how a building has been organized.

For architecture, that abstraction is powerful.

For software, it is incomplete.

A digital system has to represent something a floor plan was never designed to capture: a building whose physical structure may remain largely unchanged while its operational state changes continuously.

Consider a single commercial unit. Its geometry may remain exactly the same for years. Its coordinates do not move and its area does not change. Yet during that time, the unit may move through vacancy, leasing, fit-out, operation, temporary closure, refurbishment and vacancy again.

From a geometric perspective, almost nothing happened.

From a systems perspective, almost everything did.

This distinction matters because the way software represents a property determines what the software can subsequently understand about it.

FROM OBJECTS TO STATES

The simplest digital representation of a property is a collection of objects with attributes. A building contains floors. Floors contain spaces. Spaces have identifiers, areas and classifications. Assets have types, locations and specifications.

This structure is necessary. But it describes primarily what things are.

Operational software also needs to understand what state those things are in.

In engineering, state represents the condition of an entity at a particular point in time. A change in that condition creates a state transition. The concept sounds technical, but its consequence is fundamental.

If a system stores only the current condition of a unit, an asset or another entity, it can tell us what is true now. If it preserves the transitions that led there, it can begin to tell us how the current condition emerged.

The difference is the difference between a snapshot and a history.

And history changes what can be calculated.

A unit that has been vacant for six months and a unit that became vacant yesterday may share exactly the same current state: vacant. Treating those records as equivalent may be correct in a static database and inadequate in an operational system.

Time gives state meaning.

THE PROPERTY IS ALSO A GRAPH OF RELATIONSHIPS

State alone is still not enough.

A property is not simply a hierarchy of independent objects. Its digital representation also has to preserve relationships between them. A space may be associated with a tenant, the tenant with one or more contracts, physical assets with particular locations, and operational records with entities whose relationships themselves may change over time.

The important engineering problem is therefore not merely how much information can be stored.

It is how the information is structured and related.

This is where the difference between digitizing documents and modelling a system becomes significant. A document can contain a tremendous amount of information while remaining largely isolated. A structured model, by contrast, allows one entity to acquire meaning through its relationship with others.

The same principle applies to a property.

A floor plan tells us where the space is.

It does not tell us what the space is doing.

To approach that question, software needs more than geometry. It needs state, relationships and time.

THE DIFFICULT PART IS CHANGE

Physical buildings create an interesting engineering contradiction.

They are persistent enough that we naturally think of them as static, yet the information required to operate them is highly dynamic. More importantly, even the way the physical property is logically divided may change.

A 500-square-metre commercial space may operate for years as a single unit and later be divided into three. From one perspective, three new units have appeared. From another, the underlying space was always capable of being represented by those three entities; the previous tenant simply occupied them as one contractual whole.

That distinction is not cosmetic.

If software treats every change in configuration as the destruction of one reality and the creation of another, continuity becomes difficult to preserve. Historical information may remain technically available while losing its relationship with the structure that replaced it.

A more durable model needs to distinguish between the underlying entities and the way those entities are grouped, occupied or represented at different moments in time.

Sometimes that also means revisiting historical structure when later information reveals that an earlier abstraction was no longer sufficient. The objective is not to rewrite what happened. It is to preserve a model in which past and present remain logically comparable.

This is one of the reasons change is such a difficult problem in property software.

When a relationship changes, what should remain persistent? When several spaces become one—or one becomes several—which identity should historical information belong to? How do we preserve contractual reality without confusing it with spatial reality?

These are not interface questions.

They are modelling questions.

And decisions made at this level eventually determine what a platform can report, automate, compare and analyse.

A DATABASE IS NOT YET A DIGITAL MODEL

Modern software makes storing information relatively inexpensive.

That can create the impression that a sufficiently large collection of records will eventually describe the property.

But volume and structure are different things.

Ten years of information distributed across unrelated tables, documents and identifiers may contain the history of a building without actually representing that history coherently.

The engineering challenge is therefore not to reproduce every detail of physical reality digitally. No useful abstraction attempts to do that.

The challenge is deciding which entities, states and relationships must remain intact so that the model continues to represent the property as reality changes.

Too little abstraction and important relationships disappear.

Too much abstraction and the model becomes unnecessarily complex.

Good engineering lives somewhere between the two.

FROM REPRESENTATION TO INTELLIGENCE

This becomes particularly important when software moves beyond recording and reporting.

Automation depends on knowing the state of the entities involved. Analysis depends on consistent relationships between information. Prediction depends on historical states being interpretable in the conditions in which they actually occurred.

Artificial intelligence does not remove the need for a coherent underlying model. In many ways, it makes that requirement more important.

An intelligent layer can identify patterns across enormous quantities of information, but the meaning of those patterns still depends on what the underlying data represents. If historical relationships have been lost, entities have been incorrectly separated or combined, or different states have been treated as equivalent when they were not, greater analytical capability does not reconstruct the missing structure automatically.

Intelligence cannot recover context that the system never preserved.

That is why the engineering of a property platform begins much earlier than the intelligence placed on top of it.

THE DIGITAL PROPERTY

There is a temptation to describe the digital version of a building as a copy of the physical one.

We think that understates the problem.

A useful digital representation does not need to reproduce every wall, corridor or technical detail. It needs to preserve the structure necessary to understand how the property changes over time without losing the continuity between its different configurations.

The physical building provides the geometry.

Operations change its state.

Relationships give those states meaning.

Time turns those changes into history.

And engineering determines whether that history remains coherent.

The result is not simply a digital building.

It is a model of a changing system.

Perhaps that is the more useful way to think about property software.

A building can stand in the same place for decades while almost everything that matters to its operation changes around and within it.

The building may be static.

Its truth is not.