What Is an Architecture Intelligence Platform?
- Michael Read
- Apr 17
- 4 min read
What Is an Architecture Intelligence Platform?
Most enterprises don't have an architecture problem. They have a knowledge problem dressed up as an architecture problem.
Every Fortune 500 has rooms full of diagrams, HLDs, LLDs, compliance reports, and portfolio spreadsheets. Most of them are wrong in small, load-bearing ways: a service was renamed, a database was migrated, a mandate was updated, a team was reorganised. The diagram on the Confluence page doesn't reflect any of it. The LLD was accurate the day it was written and has been quietly decaying ever since. When an auditor asks for evidence, somebody opens Visio.
This is what an Architecture Intelligence Platform — AIP for short — is built to fix.
The short definition
An Architecture Intelligence Platform is an evidence-native, continuously-updated system of record for product and enterprise architecture. It ingests documents, source code, schemas, APIs, infrastructure-as-code, cloud inventories, and runtime telemetry, and projects them into a single baseline that every diagram, document, and report is generated from.
Three words matter in that sentence:
Evidence-native. Every claim traces back to a specific source. Not "we think the auth service talks to the user DB" — a literal pointer to the line of the OpenAPI spec, the DDL statement, or the Terraform resource that proves it.
System of record. Not a wiki. Not a diagramming tool. Not a knowledge base. The authoritative place where architecture lives — the thing every other artifact is derived from.
Continuously-updated. Architecture drifts. AIPs detect drift automatically and route it into a review queue before the model goes stale.
What it is not
This is where most conversations go wrong, so let's kill the confusion upfront.
It is not a diagramming tool. Lucidchart, Draw.io, Structurizr, and friends let you draw architecture. An AIP generates diagrams from architecture. The diagram is a projection; the model is the truth.
It is not a Wiki or a CMDB. Wikis store opinions. CMDBs store inventory. An AIP stores cited, typed facts with explicit relationships and explicit states.
It is not "LLM on top of your docs." LLMs answer questions. They do not maintain a system of record. They also hallucinate, which disqualifies them from a compliance context. An AIP uses LLMs as one extractor among many, behind a critic and a human gate.
It is not EA tooling. Traditional enterprise-architecture suites (Ardoq, LeanIX, Sparx) track the existence of things. An AIP tracks what is true about them, with evidence, in four states.
The four-state model
Every architectural claim in an AIP exists in one of four states:
Evidenced — a source says this, and the source is cited.
Inferred — the model believes this based on other evidence, and the reasoning is captured.
Missing — we know we don't know. The gap is named.
Conflicting — two sources disagree. Both are surfaced.
This is the single most important idea in the whole category. It is the difference between a document that looks confident and a document that is defensible. When a regulator asks "how do you know?" — the AIP has an answer. When the answer is "we don't" — it says so, in writing, before you ship.
Why this matters now
Three forces are putting pressure on architecture teams simultaneously:
Compliance load is rising. SOC 2 Type II, PCI-DSS, ISO 27001, NIST 800-53, and the new EU AI Act all demand traceability. "Trust us" stopped being acceptable around 2022.
AI is generating architecture content at scale. Any team with Claude or GPT-4 in their IDE is producing design docs faster than anyone can verify them. Volume without verification is debt with compounding interest.
Senior architects are leaving. When a twenty-year SME walks out, the mental model walks with them. The diagrams they left behind are 60% accurate on a good day.
An AIP addresses all three at once: it makes compliance cheap (every fact has a citation), it gatekeeps AI output (nothing publishes without passing a critic), and it captures tacit knowledge in a structured form before the SME leaves.
The six invariants
A real AIP — as opposed to a rebranded wiki — upholds six invariants:
Cite or drop. No fact without evidence.
Baseline first. Artifacts are generated from an approved baseline, never from raw documents.
YAML is authoritative. Relational, vector, and graph indices are disposable projections.
Four states. Every claim is evidenced, inferred, missing, or conflicting.
Schema before narrative. All LLM output is schema-constrained.
Human gate. Nothing publishes without review.
Break any one of these and you no longer have an AIP. You have a chatbot with a thesaurus.
What you get out
When an AIP is running correctly, the outputs are things that used to take weeks:
HLDs, LLDs, and ERDs generated on demand from the current baseline.
Impact analysis that tells you which services, mandates, and portfolios a change touches, before you ship it.
Compliance reports where every control maps to a cited architectural fact.
C4 diagrams, deployment topology, and data flow catalogues that regenerate in minutes when reality changes.
A drift queue that tells you exactly where the documented architecture and the running architecture have diverged.
This is the difference between architecture being a cost centre and architecture being leverage.
Where Vaelith fits
Vaelith is an Architecture Intelligence Platform, built around the six invariants and the four-state model. It was built because I watched the same pattern repeat for a decade: experts leave, knowledge leaves with them, diagrams decay, audits get expensive, and AI adoption made it worse by producing plausible-looking documents at scale that nobody could verify.
The bet is simple. The future of architecture documentation is not "somebody wrote it down." It's "the system of record can prove it."
Want to see an AIP in action on one of your own products? Book a 20-minute demo →
Comments