How NeoArc Works
When the same business concept is defined independently in the database, the API, and the search index, definitions drift apart. NeoArc Studio uses a model-first approach where a single domain model drives all downstream projections, keeping everything consistent by construction.
One Model, Many Projections
In most organisations, the same business concept is defined independently in multiple places. The "Customer" in the database has different fields from the "Customer" in the API, which differs again from the "Customer" in the search index. These definitions drift apart over time, creating subtle bugs and integration failures that are difficult to trace.
NeoArc takes a different approach. You define each business concept once in a central domain model. Database schemas, API contracts, search indexes, and documentation are all derived projections of that single definition. When the model changes, every projection updates to reflect it.
The Intent Graph
Traditional architecture tools create diagrams. NeoArc creates a connected graph of architectural intent. Every element, whether it is a service, a database table, an API endpoint, or a governance rule, is a typed node with typed relationships to other nodes.
This graph is not a visualisation layer on top of disconnected files. It is the underlying data structure. Diagrams, reports, and impact analyses are all views of the same graph. When you draw a connection between two services in a diagram, you are creating a real, queryable relationship that the entire system can reason about.
Governance documentation - risks, controls, non-functional requirements, architecture decisions - connects to architectural elements through typed edges. This makes compliance queryable. "Which entities lack a risk assessment?" becomes a graph traversal, not a manual audit. "Which governance rules are affected by this schema change?" is answered by following edges, not by searching through wiki pages. Coverage, drift, and impact are all computed from graph structure, making governance deterministic rather than aspirational.
Architecture as Structured Data
Every artefact NeoArc creates, whether it is a diagram, a data model, an API definition, or a governance report, is a JSON file with a deterministic structure. These files are designed for version control.
The Workflow
NeoArc fits into how teams already work. Architecture changes follow the same branch-review-merge pattern as code changes. There is no separate approval process, no separate tool to check, and no separate system to keep in sync.
Derived Views
Because the domain model is the single source of truth, NeoArc can generate multiple visual representations automatically. These views stay synchronised because they read from the same underlying data.