Engineering has moved through distinct eras, and each one changed what a “model” is and what you can do with it. Understanding that progression is the clearest way to see what intelligence-centric engineering means and why it is the natural next step.

Era 1: Document-centric

For most of its history, engineering was document-centric. Requirements, analyses, and decisions lived in specifications, reports, and slide decks. The knowledge was there, but it was locked inside prose: impossible for a computer to check, hard for a human to trace, and out of date the moment something changed.

Era 2: Model-centric

The last two decades pushed the discipline toward being model-centric. Instead of writing about a system, engineers began to build models of it, in SysML, UML, and similar languages. Structure and behavior could finally be captured and shared, which was real progress. But these models were treated as pictures, drawn and reviewed visually rather than as knowledge, and they lacked the formal semantics needed to seriously reason on them. Just as important, engineers did not drive their analyses from the model; they used it as documentation that sat alongside the real work. With nothing depending on it, nothing kept it current, and it drifted out of date, much like the documents it was meant to replace. The intelligence still stayed in the engineer’s head.

Era 3: Knowledge-centric

A third era changed that. Knowledge-centric engineering captures a system as a formal, semantic model, an ontology with precise, machine-interpretable meaning. For the first time the model is something software can seriously reason on. With formal semantics in place, the full toolbox of formal methods becomes available: automated inference and classification to derive what is implied, consistency and constraint checking to catch contradictions, model checking to verify that behavior satisfies requirements, model finding to generate or complete valid configurations, and rich queries that answer questions across the whole system. Contradictions surface on their own, and “what depends on this?” becomes a question you can actually answer. No single tool delivered all of this: different frameworks advanced different pieces, with techniques like model checking and model finding maturing in their own communities. The open-source openCAESAR platform pioneered the ontology-based strand in systems engineering, bringing formal vocabularies, automated inference, and consistency checking to demanding programs over more than a decade of research.

Era 4: Intelligence-centric

Intelligence-centric engineering is the fourth era, and it builds directly on the third. Once your knowledge is formal and computable, you can put AI to work on it, and that changes what engineers are able to do.

AI becomes an active collaborator across the engineering lifecycle. It drafts models from requirements, documents, and intent, turning weeks of manual capture into hours. It answers questions in plain language and explains how a complex system fits together, so understanding a model no longer requires deciphering it by hand. It proposes design options and trade-offs, generates analyses and gate products on demand, and watches for gaps, inconsistencies, and the downstream impact of a change before it becomes a problem. Expertise that once lived with a handful of specialists becomes accessible to the whole team, and the tedious work that consumed an engineer’s day gets automated away.

What makes this trustworthy rather than reckless is the grounding. Because the AI reasons over a formal model instead of guessing from raw text, its output is checkable against ground truth, not plausible-sounding fiction. You get the speed and reach of AI without giving up the rigor engineering demands. The model stops being something you maintain and becomes an active source of engineering intelligence that works alongside you.

That is the definition in one line: intelligence-centric engineering treats engineering knowledge as formal models you can reason on and compute over, then puts AI and automation to work on them.

Why now

Two forces make this both possible and necessary.

The first is the maturation of formal, ontological modeling, the knowledge-centric era described above. Decades of research gave us languages with the rigor to express engineering knowledge unambiguously and the tooling to reason over it at scale. What was once academic is now practical.

The second is AI. Large language models are extraordinary at language but unreliable on facts; they hallucinate. Point one at your raw engineering data and you get confident answers you cannot trust. But ground that same AI in a formal model of your system, one with explicit concepts, relationships, and constraints, and its answers become checkable against ground truth. Formal models are exactly the missing context that makes AI dependable for engineering.

This pairing has a name in AI research: neurosymbolic AI, the combination of neural methods like large language models with symbolic methods like formal logic and ontologies. Intelligence-centric engineering is neurosymbolic AI brought to engineering, where the rigor of symbols makes the fluency of neural models trustworthy.

The three foundations

In practice, an intelligence-centric platform rests on three foundations working together:

  • Logic. Knowledge is captured as formal models with the semantics to be reasoned over: automated inference, classification, consistency checking, and validation turn static descriptions into actionable knowledge. This is the knowledge-centric core.
  • AI. Agents generate, explain, query, and navigate those models while staying grounded in their formal semantics, so assistance is trustworthy rather than plausible-sounding.
  • DevOps. Engineering knowledge becomes a first-class artifact: version-controlled, automatically validated in continuous-integration pipelines, peer-reviewed, and continuously delivered, just like software.

Logic makes the knowledge trustworthy. AI makes it accessible. DevOps keeps it alive. Together, they turn a static model into a living source of engineering intelligence.

Why it matters

The payoff is not modeling for its own sake; it is engineering you can rely on:

  • Consistency at scale. Contradictions and gaps are caught automatically, not discovered in review months later.
  • Traceability that holds. Because relationships are explicit and computable, you can actually trace dependencies across the whole system.
  • Trustworthy AI assistance. Engineers get answers grounded in their real models, not a chatbot’s best guess.
  • Knowledge that compounds. Captured formally and versioned like code, engineering knowledge accumulates instead of evaporating when a project ends or a person leaves.

From idea to practice

None of this is hypothetical. The knowledge-centric foundation grew out of more than a decade of research at Modelware Labs and was proven in the open through openCAESAR. OML Code takes the next step: it productizes that foundation and adds the AI and DevOps layers, delivering an intelligence-centric engineering platform built on Logic, AI, and DevOps.

If your models are still pictures, there is a better way to work. See OML Code in action.