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

Engineers who build systems need a way to talk about the world. They need to agree on what exists, what matters, and how to describe it. Making an internet 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. A part of system engineer's work is to describe the interaction between these systems, the business processes, the structure of the organization, software architecture of the automation. The tool they reach for is an ontology — a framework that carves the world into categories useful enough to work with.

Let's talk about a popular, "common sense" ontology. It descends, loosely, from Aristotle, and pictures the world in a straightforward and simple way:

• The world is made of objects, which occupy three-dimensional space.
• Each object carries attributes.
• Objects have types, and types may belong to broader, more generic types.
• Attributes of a particular object also have types which, in turn, may belong to broader supertypes, and so on.

Take Garfield. He is an object of type cat. A cat belongs to a type animal, which is a subtype of living being, and so on. His attribute color is set to orange. This orangeness is an instance of the attribute orange of type color, belonging to an attribute supertype visible quality.

If Garfield has a son, Barfield, we record a son attribute on Garfield pointing to Barfield, and a father attribute on Barfield pointing back. The relationship spans over two separate places – one on each object – rather than in a single, stand-alone description.

Now suppose Garfield goes for a walk. To represent this, we update his coordinates. We change an attribute, and then change it again, and again. But the ontology has no way to express the walk itself. It can describe where Garfield is; it cannot describe what Garfield is doing. Change, in this framework, gets lost in the cracks between discrete, isolated snapshots of reality.

Software engineering leans on ontologies for at least two reasons. First, they need to describe the engineering process by which they build things – the teams, the customers, the platforms. Second, the software itself must model whatever real world processes it automates. Ashby's law implies as much: a controller must match the variety of the system it controls, and a model that misses important structure will produce software that misses important behavior.

Widely used enterprise architecture frameworks, such as TOGAF, Zachman, and ArchiMate, do not solve these four 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 ask: if the system has been migrated to the cloud, refactored, had its database replaced, and the development team rotated three times, is it the same system? TOGAF's 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. Let's see how.

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.

This 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.

For this kind of power we pay with complexity. A 4D ontology is harder to learn, and the models it produces look unfamiliar to engineers raised on entity-relationship diagrams and class hierarchies. But the payoff is an ontology where change and identity are built into the foundations.

Most engineers haven't heard of Giambattista Vico – even for philosophers he is a niche read. Surprisingly, a Neapolitan prophessor of rhetoric came close to the modern philosophy of engineering three centuries ago.

Vico was a Neapolitan professor of rhetoric who spent most of his career underpaid and ignored. He published his major work, the Scienza Nuova, in 1725, paying for the first edition by selling a ring. The book is strange, ambitious, and badly organized. It attempts nothing less than 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: a society so saturated with abstraction and formal rationality that it loses contact with the concrete, the particular, the made. It forgets how to understand its own institutions because it can only analyze them, not feel them. Then it collapses, and the cycle begins again.

This is where Vico is commonly misread. He is often labeled a Counter-Enlightenment thinker, an enemy of reason. He wasn't. He was an enemy of a specific kind of reason — the Cartesian kind, which starts from abstract axioms and deduces its way to truth. Descartes said: I think, therefore I am. Clear and distinct ideas are the foundation. Geometry is the model of knowledge. Vico replied: geometry works because we invented it. We can know it with certainty because we constructed it ourselves. He didn't reject science. He asked a sharper question: what can we truly know, and why?

His answer is compressed into a formula: verum ipsum factum. The true is the made. We have genuine knowledge of what we ourselves have made. Mathematics — yes, we made it, we can know it fully. History, law, language, institutions — yes, made by humans, knowable by humans. Nature — no. We didn't make it. Only God, its maker, has that knowledge. We can observe nature, measure it, build useful models, but we cannot know it the way we know our own creations.

Set aside the theology for a moment. The engineering insight is in the principle itself. Vico is not saying that made things happen to be easier to study. He is saying 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 after the fact. 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.

Notice what this gives us that 4D extensionalism doesn't. The perdurantist says: your system is a four-dimensional object extended through time, and its identity is its complete spatiotemporal history. Good. But that history, for a perdurantist, is a sequence of states — temporal parts, one after another, like frames in a film. Vico says: for a man-made thing, the history is not a sequence of states. It is a sequence of acts of making. Each temporal part was produced by someone who chose it over alternatives, for reasons, under constraints. Strip out the acts of making and you have an accurate but inert skeleton. You know what the system looked like at every point in time. You do not know why.

This is an epistemic claim, not an ontological one. 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. For natural objects, observation and measurement are the best we have. For artifacts, we can do better — or rather, we must do better, because the observable properties of an artifact systematically underdetermine 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?

• lesser known, "father of humanities"
• "New science book": cyclical history, two approaches to knowledge, nature vs man-made things, warning of barbarian rationalism
• misconceptions: is not anti-enlightment
• Influences on Hegel and others
• Verum ipsum factum: 4D + intentions + how (but only for man-made objects)
  • Epistemic, not ontological
  • Process, not a snapshot
  • The history of a human-made thing is not just a sequence of states; it is a sequence of acts of making.

• A complete framework would need both: Einstein's contribution (things are their spatiotemporal extents) and Vico's contribution (for artifacts, those extents are structured by intentionality).
• Vico saw this earliest, but restricted it to the human domain. Physics universalized it. Applied ontology operationalized it for engineering. But the engineering tradition lost the intentional dimension that Vico considered essential.
• 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.)

The lost rationale problem. People change engineered systems for reasons. In this ontology, these reasons have nowhere to live. They float outside – in emails, slack channels, they are shared over company paid lunches and occasionally mentioned to the new hires. Every developer who has built something nontrivial and returned to it a year later knows the feeling: a design decision that once seemed obviously right now looks baffling. Why did I do this? Was there a constraint I've forgotten? The knowledge of why is lost, leaving the developer afraid to touch anything. Everything becomes brittle, or at least seems so. Cleaning a mess may cost you weeks of time, but in the end you'll rediscover why the said mess is still the best cope. In the end, time spent, knowledge recovered, but no progress on the product itself.

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.