System engineering standards are missing the last step to reinvent Giambattista Vico

Engineers need a way to talk about the world. They need to agree on what exists, what matters, and how to describe it.

For example, making an online shop means automating a part of some organization which has employees, clients, logistics, processes, reports to the tax office and so on. Usually, a team of engineers works on this automation. That makes three systems involved: the organization and its clients is the supersystem, the automation is the target system, and the developer team is the third one. The system engineering approach includes describing these systems and their interactions.

For these descriptions, engineers use ontologies – frameworks that carve the world into categories useful enough to work with.

Widely used enterprise architecture frameworks, such as TOGAF, Zachman, and ArchiMate, do not solve these problems at the level of ontology. Instead, they work around them.

The usual approach goes like this:

1. Describe the system as it is now.
2. Describe how you want it to be.
3. Identify the gaps between the current and desired systems, build a roadmap.

TOGAF's Architecture Development Method formalizes this into phases. Each phase produces documents and diagrams that represent a snapshot of the system. Engineers keep snapshots connected through reviews, processes and conventions. But the ontology itself can not represent a transition between snapshots. Transition is implied, not modeled.

The identity problem is left to human judgement, armed with the robust weaponry of "following conventions". You might wonder: if the system has been migrated to the cloud, refactored, had its database replaced, while the development team rotated three times, is it the same system, team, process? TOGAF gives a clear answer: whatever the governance board decides. This risks inconsistency, and attempts to model both current and future states often end up blending them together, or mixing them up.

So, when a standard does not provide native ways of describing changes, people try to make up for it with processes, discipline, and documentation. This brittle practice works until someone changes jobs, retires, budgets get cut, or when the team just can't keep up with complexity and the pace of changes.

However, there are ontologies in other system engineering standards that handle changes more gracefully. They place objects not in three-dimensional space, but in four-dimensional space-time, so an object extends through time the way it extends through space.

The key is to stop thinking of objects as three-dimensional things that persist through time, and start thinking of them as four-dimensional things that extend through time. A cat does not exist "at" various moments; it is a long, winding entity stretched across space-time, spanning from its first cry to the last nap. We only get to see a thin slice of it – the cat right now. The cat-on-Tuesday and cat-on-Wednesday are both connected parts of the cat, just as its ears are connected to its head. An Aristotelian cat was made of space and time happened to it; nowadays, cats are made of space, and time. This idea is called 4D-extensionalism, or perdurantism. The common-sense ontology is an example of the opposite approach, endurantism, which posits entities are wholly present at each moment.

Perdurantism is not a trick of language. It restructures the ontology and takes on the problems we identified.

The snapshot problem disappears. Two snapshots of a system are no longer isolated pictures that someone must mentally connect – the system itself is the connection.

The moving target problem becomes manageable. You can describe whatever temporal extent you know about and leave the rest open. The system grows a new temporal part tomorrow; you add the description of that part when you have it. The existing description is not "outdated" — it is a complete and accurate account of the portion of space-time it covers. You are not racing to finish before reality moves on. You are building a description that extends alongside reality.

The identity problem gets a better framing. The ship with all new planks is the same 4D ship: an early temporal part has old planks, a later temporal part has new ones, and both parts belong to the same 4D ship. The software module rewritten line by line is one 4D entity whose later temporal parts contain different code. The team whose members have all been replaced is one 4D team: its early parts include Alice and Bob, its later parts include Alex and Rob. The knowledge that the team possesses, however, also gets localized in space-time, so it can be lost if all its bearers leave the team.

The idea that objects extend through time came from philosophers, debating how ordinary objects persist. One camp – the endurantists – held that an object is wholly present at each moment it exists. The other – the perdurantists – argued that objects have temporal parts, just as they have spatial parts.

There was a related debate on time: presentists think that only now exists, and eternalists consider time is eternal, so what was in the past or will be in the future simply exists.

• Eternalism pairs naturally with perdurantism: if all times genuinely exist, then an object's temporal parts at different times all exist too.
• Presentism pairs naturally with endurantism: if only the present exists, there are no past or future temporal parts to have.

Other pairings are possible but problematic, so let's stick with the classical ones. Common-sense ontology is endurantist and presentist, 4D-objects are perdurantist and eternalist.

Quine developed early versions of perdurantism; David Lewis gave it its most influential formulation; Ted Sider later provided rigorous formal defenses.

Chris Partridge and his colleagues at KPMG Consulting transfered the ideas from philosophy to engineering in the late 1980s. Working on a legacy modernization project in the finance sector, they developed BORO – the Business Objects Reference Ontology. BORO explicitly adopted perdurantism for a practical reason: when two departments disagreed about whether a reorganized division was "the same" entity, BORO gave them a framework to describe exactly what had changed and what had not, without requiring anyone to win an argument about identity. Partridge described the method in his book and BORO went on to be applied in finance, defence, energy, and oil and gas.

From there, BORO's ideas passed into the IDEAS Group which created a shared formal ontology for data exchange between defence departments of US and their allied countries. The ontology development was led by Ian Bailey of Model Futures and BORO Solutions contributed too.

The aforementioned DODAF framework absorbed this foundation; in its second version it introduced DM2, the four-dimensional and extensional DoDAF Meta-Model.

Another branch: ISO 15926, a standard developed for the process industries. It grew out of a European Union ESPRIT project called ProcessBase, begun in 1991, and was further developed by the EPISTLE consortium through 2003 under the lead of Matthew West at Shell. Its problem was lifecycle data integration for industrial plants: assets were built, modified, maintained, and decommissioned over decades. BORO seems to be an influence here as well, but ISO 15926 also had its own independent development history rooted in industrial data management.

In all cases, the perdurantist approach is not adopted because of its elegance, but because people ran into real problems that conventional ontologies could not solve. The philosophy provided solutions and useful ways of thinking.

Now how Giambattista Vico fits into this picture? Most engineers haven't heard of him– even for philosophers he is a niche read. Vico was a Neapolitan professor of rhetoric who spent most of his career underpaid and ignored. I am impressed at how close his ideas got to the modern philosophy of engineering.

Vico published his major work, the Scienza Nuova (Italian for New science), in 1725, paying for the first edition by selling his ring. The book is strange, ambitious, and badly organized attempt to build a unified science of human civilization: how nations arise, how languages form, how laws develop, how cultures mature and collapse. Vico argued that civilizations move through recurring cycles – a divine age of myth and ritual, a heroic age of aristocratic codes, a human age of reason and democracy. At the end of each cycle comes what he called the barbarism of reflection. People start to apply rational approaches universally and outside their scope: to the foundations of politics, ethics. The society saturated with abstraction and formal rationality loses contact with the concrete, the particular, the made. It forgets how to understand its own institutions because it can only analyze them, not know them. Then it collapses, and the cycle begins again.

Vico is commonly mistaken for an anti-Englightment thinker, but he wasn't an enemy of reason. For Descartes, cogito ergo sum and clear and distinct ideas are the foundation, and mathematics is the model of knowledge. Vico notices that we doubt our knowledge about mathematics less than what we know about reality because we made mathematics. Makers know more about their creation than anyone else can possibly know. So he asked: what can we truly know, and why?

His answer is a formula: verum ipsum factum, the true is the made. We have genuine knowledge of what we ourselves have made. Mathematics – we made it, we can know it fully. History, law, language, institutions – same, made by humans, knowable. Nature is God's creation, therefore the full knowledge about nature is inaccessible to us. We can observe nature, measure it, build useful models, but that's it.

The engineering insight is in the principle itself. Vico means that making and knowing are the same act. When I build a system, every decision I make – this interface, this data structure, this trade-off – constitutes my knowledge of it. The knowledge isn't a description I write afterwards. The knowledge is the making. The moment I stop making, the knowledge begins to decay. Which is exactly the experience we started with: staring at our own code, unable to reconstruct the reasons.

So to know something, you need to deeply understand its history, and rationale behind changes. Notice what this goes further than 4D extensionalism doesn't. For a perdurantist, anything is a four-dimensional object extended through time, and that time slice is a sequence of states. For Vico, a man-made thing is special, its history is not a sequence of states, but of acts of making. Each temporal part was produced by someone who chose it over alternatives, for reasons, in a context, under constraints. Strip out the acts of making and you have a corpse where an organism used to be. You know what the system looked like at every point in time. You do not know why.

Make no mistake: Vico is not saying made things are built out of different stuff than natural things. He is saying that knowing a made thing requires a different method than knowing a natural thing. So, it's a claim about knowledge, not about being – an epistemic statement, not an ontological one. For natural objects, observation and measurement are the best we have. For artifacts, we can and must do better, because the observable properties of an artifact are not enough to describe its design. Two systems can look identical in structure and behave identically in all tested scenarios, yet be different systems because they were made for different reasons, with different constraints, carrying different trade-offs. The reasons are invisible in the snapshot. They live in the history of making.

Vico's influence ran underground for a century, then surfaced everywhere at once. Hegel's idea that history is intelligible only through its own development — Vichian. Marx's claim that we understand society by understanding how it was produced — Vichian. Collingwood's argument that history is the re-enactment of past thought — Vichian. The hermeneutic tradition from Dilthey to Gadamer, with its insistence that understanding a human creation means recovering the intention behind it — all of this traces back, directly or indirectly, to the professor from Naples who couldn't get a better chair.

But none of these inheritors had our problem. They were studying civilizations, not configuring distributed systems. The question for us is narrower and more practical: can Vico's principle be made to work inside a formal ontology for systems engineering? Can we preserve the maker's knowledge — not just as documentation on the side, but as a structural feature of how we describe systems?

Design rationale sits outside the metamodel entirely. Some teams keep Architecture Decision Records as separate documents, but these records share no connection to the formal architecture description. They do not share the same underlying foundations nor language. They decay. They get abandoned. Sometimes, or rather often, they are simply never written at all.

The lost rationale is not addressed but might find a home. The design decisions are localized in space-time and tie the system that was built to the alternatives that were rejected. To the best of my knowledge, no commonly used system engineering standard puts the design rationales into ontologies, but the 4D approach makes room for it.

• The practical upshot: if you're building systems, modeling systems, or managing the evolution of systems, you need both the 4D spatiotemporal extent and the record of why each making-decision was made. The first without the second gives you a skeleton; the second without the first gives you folklore.
• IBIS, QOC, DRL, Kruchten's ontology capture rationales but are not integrated into any serious ontology
• Incorporating into ontology:
  • Making Acts as 4D individuals, related to system's temporal parts, agents, intentional content (see next point)
  • Intentional content: decision (selection of one of possible worlds + possible temporal parts) + rationale + Context (temporal parts of the environment)
  • Architecture Devision Records are part of the ontology now

• Imagine if your code is not just a text but
  • a history of diffs annotated with rationales behind every change
  • and also every entity has semantic links to relevant entities

  • agents have much better context for every code entity, instead of inferring their meaning from the code https://huggingface.co/papers/2503.15231?utm_source=chatgpt.com

    For each “public” entity, store:

    • Spec hooks (tests/properties/protocol checks)
    • Invariants (“must hold” statements)
    • Decision record (rationale, alternatives, consequences)
    • Links (depends-on, refines, deprecates, implements, constrained-by, etc.)