CelinQ Insights · No. 89 · Last technically reviewed: August 2026
How to Keep Architecture Documentation Up to Date
Most architecture documentation is accurate exactly once: the moment it's exported. Here's why that keeps happening, and what actually fixes it.
Short answer. Documentation goes stale because generating it and maintaining it are treated as separate acts — someone exports a snapshot, the model keeps changing, and nothing tells anyone the export no longer matches reality. Continuous architecture documentation fixes this by tracking, for every generated publication, exactly which model revision it came from, and comparing that against the model's current state so staleness is a fact you can query, not something you discover by re-reading a document and hoping you'd notice a discrepancy.
Why documentation goes stale almost immediately
The pattern is familiar in most architecture practices. Someone exports the model — a set of diagrams, an application catalogue, a Word document assembled by hand from screenshots — and circulates it. The export is accurate on the day it's made. Then the model keeps evolving: an application is retired, an integration is added, an owner changes. Nothing about that ordinary, healthy modelling activity updates the document, because the document was never connected to the model in the first place — it was a one-time transcription of it.
Nobody notices immediately, which is precisely the problem. A stakeholder reads the six-month-old document, forms a decision based on what it says, and the gap between the document and the real model only becomes visible when that decision turns out to be based on something that changed months ago. The document didn't fail loudly. It just quietly stopped being true, and nothing in the process was designed to tell anyone when that happened.
What continuous architecture documentation actually means
The fix is not "regenerate the documentation more often" — that's a schedule, and any fixed schedule is either too frequent to be worth the effort most of the time, or too infrequent to catch the specific change that mattered. The fix is making staleness a fact the system can tell you, on demand, rather than something a human has to notice.
That requires one specific piece of bookkeeping: every generated publication needs to record exactly which model revision it was generated from. Once that's recorded, answering "is this still accurate" becomes a comparison — the publication's recorded revision against the model's current revision — rather than a judgement call or a full re-read of the document against the live model.
What this looks like as a real capability, not a concept
This is not a hypothetical architecture. CelinQ's Continuous Documentation works exactly this way today, and it's worth being precise about what's real versus what's still ahead, in the same spirit as every comparison on this site.
Staleness detection
Every generated publication records its source revision. Comparing it against the workspace's current revision — and reporting exactly how many revisions behind it is — is a real, tested API capability.
View exactly what changed
A deterministic Change Intelligence endpoint reports precisely how many elements were created, updated or deleted since a publication's revision — addressable directly by the publication's own id, no manual revision lookup required.
Regenerate
A single API call re-runs the exact publish profile behind a stale publication, addressed by that publication's id — the "make it current again" half of the workflow.
What isn't built yet, stated as plainly as what is: none of the three capabilities above have a Control Plane button wired to them today — they're real, tested API endpoints, not yet a one-click experience in a browser UI. There's no automatic "regenerate whenever stale" toggle; every regeneration today is an explicit call. And staleness is currently computed against the whole workspace's revision count, not a per-publication analysis of which specific model objects a given document actually depends on — so a change to a completely unrelated part of the model will currently flag a publication stale even if nothing the document actually describes was touched. That finer-grained dependency tracking is real, named future work, not something already quietly working.
The underlying documentation generator itself is not a preview. CelinQ.Publish produces a genuine static, searchable portal — a landing page, full-text search, a page per package and per diagram with the diagram rendered inline — publishable to a local folder, a zip, SharePoint or SFTP, on demand or on a schedule. Continuous Documentation sits on top of that real generator; it's the staleness-awareness layer, not a promise about the generator itself. The full documentation page covers what's generated and where it can go.
What to actually do with this today
Even without a UI button, a team can build a real workflow around what already exists: check a publication's staleness before circulating it to a stakeholder, pull the change list when it is stale to understand exactly what moved before deciding whether it matters for the reader, and regenerate through the API when it does. That is meaningfully better than the status quo most architecture practices operate under today — a document nobody has a reliable way to check the currency of at all.
Frequently asked questions
Does regenerating documentation require AI? No — page content (package summaries, element listings, diagram context) is produced deterministically from the model. AI, where enabled, can only enrich generated prose on top of those deterministic facts; it never invents content the model doesn't contain.
Can I export continuously updated documentation as a PDF? Not today — output is HTML, inline SVG and JSON. PDF and Word export are not built.
Does staleness mean the document is wrong? Not necessarily — it means the model has advanced since the document was generated. Viewing the actual changes tells you whether anything the document describes was affected.
Related reading
Documentation
What gets generated, where it can be published, and the full "what's not built yet" table.
How to Generate Documentation From Archi
The same generator, applied to an Archi-sourced workspace.
A Searchable Architecture Knowledge Base
How the same graph and revision history double as the foundation for search.