Xtrable
Every architecture has a centre: the entities the business actually runs on, and how they relate. In most tool chains that centre is implied, scattered across an ER diagram, a stack of migration scripts, a handful of API specs and a wiki nobody trusts. NeoArc makes it explicit and puts it first.
The model is the source of truth
You describe your entities, their properties and their relationships once, in a single model. Properties use clear, vendor-neutral types that capture intent rather than a specific database's syntax. This is the canonical truth about your system, and everything else is derived from it.
Databases, schemas and APIs are projections
From that one model NeoArc projects forward along a chain. A database is one projection of the model. A schema is another. A REST or GraphQL API is another again. Each one maps its own elements, its tables and columns, its fields, its operations and tokens, straight back to the model elements they came from.
Because the projections are derived rather than re-authored, they cannot wander off on their own. The API you publish and the database you run are the same architecture, expressed for different audiences.
Author in one place, check in one place
- No duplication. A "Customer" entity is defined once, not redrawn in four diagrams and three schemas.
- No silent drift. Change the model and every projection knows immediately. There is nothing to keep in sync by hand.
- One mental model. Anyone can start from the centre and follow the structure outward, instead of reverse-engineering it from artefacts.
Why it matters
When the model and the system are the same thing, architecture stops being documentation you hope is current and becomes infrastructure you can rely on. That single shift is what makes everything else in NeoArc possible: the impact graph, governance that actually reaches the data, and health checks that mean something.