Your architecture documentation is an intelligence asset
Service topology. Database schemas. Auth boundaries. API surfaces. The same information your engineers need to build the system is the information anyone else would need to understand it. Where you store that information decides who can reach it.
Read how security shaped the productYou already know this is sensitive
Military organisations classify network topology as SECRET. Banks treat system architecture as confidential internal material. Nuclear facilities restrict control documentation to named individuals with security clearance. The information is a map, and the map is valuable.
In every other setting, the same information sits in tools with web interfaces, API endpoints and network-accessible storage. Not because anyone decided it should. Because that is what the tools do.
The exposure is structural
Architecture documentation describes service boundaries, data flows, authentication and authorisation. It has to. That is how it stays useful to the people building the system. The same property that makes it useful internally makes it valuable to anyone else who wants to understand your estate.
Where the documentation lives decides who can reach it. A cloud product extends reach to the vendor, the vendor's subprocessors, and anyone who compromises either. A web interface is reachable from any compromised machine on the network. An API is reachable programmatically. A file share is reachable by every account with network credentials. None of these are failures of configuration. They are properties of the tool category.
The only documentation an attacker cannot reach is documentation that is not on the network at all
Modern security assumes breach. Zero-trust architectures treat every internal request as potentially hostile.
Taking the documentation off the network is only half the fix. If you still run four separate tools, one for diagrams, one for schemas, one for APIs, one for narrative, you now have four offline tools that silently diverge. The same structural problem that creates the exposure also creates the drift. One source of truth, not four, is the only way both problems resolve at once.
Define once. Derive everything.
One model. Every view, document and schema derived from it.
One canonical model
Your entire architecture - entities, properties, relationships, APIs and schemas - lives in a single graph. Not a flat document. A connected model that understands what everything is and how it relates to everything else.
The Intent Graph
Every property, document, component, API endpoint and schema is connected by lineage. The graph captures structure and purpose, not just data, so every reference is a trail the system can follow.
Live projections
The graph enables the creation of live projections. ERD views, graph diagrams, search profiles and API serialisation rules are all derived from the model automatically, without manual exports or duplication.
Visible by construction
Derived views reference the model by name. When a property is added, renamed or removed, the system flags every projection, schema and contract that depends on it and surfaces the change for review. Drift is not eliminated. It is made visible the moment it happens, in reports and within the projection itself, instead of discovered months later in production.
One model. Every view derived. Nothing maintained separately.
What model-first makes possible
These are not features bolted onto a wiki. They are structural consequences of the model-first approach. They cannot exist in tools that treat documents as the source of truth.
Vendor-Neutral Types
Define properties once. The system resolves them to PostgreSQL, SQL Server, MongoDB, or any target.
Profile-Driven Resolution
Switch database or search vendor without re-drawing. Compare technologies from the same model.
Live Data Views
Every view reads from the model at render time. Add a property, every projection updates.
Field-Level Impact Analysis
Trace a property from model to database column to search field to API response. See what breaks.
Shared Property Sets
Define audit fields or tenancy identifiers once. Every entity inherits them. Change once, propagate everywhere.
Managed Entity Lifecycle
Deprecate an entity, track every reference, migrate to a replacement. One operation.
One tool, not a toolchain
Everything in one place, one file format, one security boundary. No integration gaps. No synchronisation. No scattered attack surface.
Governance that computes, not governance that hopes
Risk assessments, security controls, and NFRs connect to architectural nodes through typed edges in the Intent Graph. Compliance and coverage are not estimated. They are computed from the graph structure.
When an entity changes after a governance review, the system detects the structural change and flags the documentation as stale. The architect reviews, confirms, and re-approves. No spreadsheets. No manual cross-referencing. No silent decay.
Governance rules are typed declarations, not free-text policies. "Risk blocks must govern model entities" is a machine-readable expectation that the system validates on every change. Compliance checking is deterministic. Given the same architecture and the same rules, the system always produces identical results.
Runs on your machine. Stays on your machine.
Fully Offline
Every feature works without internet. No degraded mode. No missing capabilities.
Git-Native Storage
All files are JSON in your repository. Branch, diff, merge, review in pull requests.
Air-Gap Ready
No telemetry, no licence servers, no external calls. Three build tiers to full sovereignty.
Publish Anywhere
Static website, local file site, or PDF. Host on your infrastructure or browse from a USB drive.
Architecture documentation is worth the same protection as the infrastructure it describes
NeoArc Studio is built that way by default. A structured evaluation takes an afternoon, not a quarter.
Read the Thinking Behind the Platform
Three papers covering security, consistency, and governance in architecture documentation.
Architecture is Reconnaissance
Why your architecture docs are a security-sensitive asset.
Download PDF