Model-First Architecture
NeoArc Studio builds every architectural artefact from a single, authoritative data model. API schemas, database DDL, search indexes, governance documentation, and visual diagrams are all projections of one source of truth. Change the model, and every downstream artefact updates. Break a contract, and the system tells you before anything reaches production.
Every architecture team faces the same fundamental problem: data definitions are scattered across dozens of artefacts. The database schema says one thing. The API contract says another. The documentation says something else entirely. When a field is renamed in the database, nobody updates the API spec. When a new property is added to the API, nobody updates the search index. When a compliance requirement changes, nobody knows which systems are affected.
This is not a tooling gap. It is a structural one. Traditional architecture tools treat each artefact as independent. A diagram is a file. A schema is a file. They sit next to each other in a folder with no awareness of each other. The relationships between them exist only in people's heads.
NeoArc Studio takes a fundamentally different approach. Every entity, property, and relationship is defined once in a central data model. Everything else - API schemas, database DDL, search indexes, Data Views, governance documentation - is a projection of that model. The model is the source of truth. The projections are derived. And the Architectural Intent Graph traces every connection between them.
The Problem with Artefact-First Architecture
Consider what happens in a typical architecture workflow when a team needs to rename a field from userName to displayName.
This is not a hypothetical scenario. It happens in every organisation, on every project, continuously. The cost is not just wrong documentation. It is broken integrations, compliance gaps, wasted engineering time, and architectural decisions made on outdated information.
How Model-First Changes Everything
In NeoArc Studio, the same rename takes one action. You rename the property in the model. Everything else follows.
The Architecture of Model-First
The model-first approach has four layers, each building on the one below it.
One Property, Three Projections
The most powerful aspect of model-first design is that each property can be configured independently for each output domain. A single property can appear differently in the database, the search index, and the API, all controlled from one place.
What This Enables
Model-first architecture is not an abstract principle. It enables concrete capabilities that are impossible in artefact-first tools.
Who Benefits
The Model-First Capability Map
Every capability in NeoArc Studio traces back to the central model. The sections below cover each capability in detail.