CelinQ Insights · No. 10

Audit trails public-sector architecture actually needs

What auditors ask for, and how to have the answer ready before they ask.

In most public-sector organisations, the architecture repository is not primarily a design tool. It is a record. It is the place where someone has written down, formally, that this application supports that business capability, that this data flow crosses that trust boundary, that this system was decommissioned on this date and its responsibilities moved somewhere else. Long after the design conversation has ended, the model is what remains, and it is what an auditor, a supervisory body, a new director, or a court of accounts will eventually read. The people who built the model rarely think of it this way while they are building it. They think about the diagram in front of them. But the moment an external party asks a pointed question about a decision made three years ago, the repository stops being a design surface and becomes evidence, and the standard it is held to changes completely.

The uncomfortable thing about that transition is that it is retroactive. You do not get to decide, at the moment the question arrives, that from now on the model will be maintained to evidentiary standard. The evidence either exists or it does not, and it was either captured at the time or it was reconstructed afterward from memory and email. Auditors know the difference, and they are trained to distrust the reconstruction. So the real question for anyone running an architecture practice inside a regulated or publicly accountable organisation is not whether the current model is accurate. It is whether the history of how the model became accurate can survive being looked at by someone whose job is to doubt it.

What auditors are actually testing

It helps to be precise about what an audit of architectural records is really probing, because it is easy to prepare for the wrong thing. The naive assumption is that the auditor wants the model to be correct, and that a clean, well-structured, internally consistent repository will satisfy them. Correctness matters, but it is not the thing under test. What is under test is the reliability of the process that produced the record. An auditor is asking, in effect, whether the organisation can be trusted to know things about its own systems, and the evidence for that trust is procedural, not aesthetic.

That means the questions cluster around a small number of themes that have very little to do with how good the diagrams look. Who made this change, and were they authorised to make it? When was it made, relative to the decision it was supposed to reflect? Was the change reviewed by anyone other than its author before it became the official version? If two people disagreed about how something should be modelled, how was that disagreement resolved, and is there a trace of the resolution? If a fact was removed from the model, can you show what it was before it was removed, and can you show that its removal was deliberate rather than accidental? None of these are questions about the present state of the model. Every one of them is a question about its history, and specifically about whether that history is complete and tamper-evident.

This is the point where a great many architecture practices discover that their tooling was designed for a different purpose. A repository that stores only the current state, or that keeps history in a form that can be silently overwritten, cannot answer these questions with confidence. It can produce the current model, and it can produce a backup from some arbitrary date, but it cannot produce a continuous, ordered account of who did what and when. The gap between "here is the model" and "here is the defensible history of the model" is exactly the gap an auditor is trained to find.

How the gap opens in practice

The gap does not open because anyone is careless. It opens because of the ordinary mechanics of how teams share a Sparx Enterprise Architect repository. Consider the common arrangement where several architects work against a single shared database. Everyone is editing the same store, more or less at the same time. The repository reflects whatever the most recent save happened to contain. If two people touched overlapping parts of the model, the second save quietly wins, and the first person's contribution is simply gone, with nothing recording that it ever existed or that it was displaced. There was no decision to discard it. There was no review. There was a race, and the race had a loser, and the loser's work vanished without a trace in the very record that is supposed to be trustworthy.

Now imagine that displaced contribution mattered. Perhaps it was the correct classification of a system that handles citizens' personal data, and the version that survived was the older, looser classification. Two years later an incident occurs, and the question becomes: did the organisation know this system held sensitive data, and if so, why was it not protected accordingly? The honest answer might be that yes, an architect did know, and did record it correctly, and their record was overwritten by an unrelated save on an unrelated afternoon. But that answer cannot be given, because there is no evidence of it. The record shows only the looser classification, from beginning to end, as if the correct one had never been entered. This is not a hypothetical failure of diligence. It is a structural property of last-write-wins sharing, and it converts genuine diligence into apparent negligence.

The other common arrangement, where people work in separate files and periodically hand them around, fails differently but just as badly for audit purposes. Here the history is scattered across a series of exported files, email attachments, and shared-drive folders with names like "final", "final v2", and "final reviewed MJ". Nobody can say with authority which of these was the official model on a given date, because there was no single official model — there was a cloud of near-copies, reconciled by hand whenever someone had time. Reconstructing the state of the architecture as it stood at a particular moment becomes an exercise in archaeology, and archaeology is precisely what an auditor will not accept as evidence.

What a defensible history looks like

A history that can survive scrutiny has a small set of properties, and they are worth stating plainly because they are the properties that ordinary file-sharing and single-database working cannot provide. It has to be complete, in the sense that every change that reached the shared model is present in the record, including changes that were later reversed. It has to be ordered, so that you can reconstruct the exact sequence in which things happened and therefore the state of the model at any past moment. It has to attribute each change to a person, so that authorisation can be checked. And it has to be resistant to silent alteration, so that the record itself cannot be quietly edited to say something more convenient after the fact.

CelinQ is built around exactly this shape of history, not as a compliance feature bolted onto a design tool but as a consequence of how synchronisation works. Each architect edits a local repository at full speed, and a background companion syncs each save with a shared workspace on a server the organisation runs itself. Because every save is a discrete, attributed event that flows into the shared workspace, the workspace accumulates a complete ordered revision history as a natural by-product of people simply doing their work. Nobody has to remember to snapshot the model, name a file carefully, or write down who changed what. The record is produced by the same action that produces the design.

The merge engine matters here more than it might first appear. CelinQ Fusion performs a deterministic, reproducible three-way merge at the granularity of individual model facts. When two architects have changed different things, both changes are kept and combined; there is no race and no silent loser. When they have genuinely changed the same thing in incompatible ways, the conflict is isolated and made explicit rather than resolved by whichever save happened to arrive second. This is the difference between a history that records what actually happened and a history that records only what survived a series of accidents. For audit purposes it is the whole game. An auditor asking "what happened to the correct classification that was entered and then lost" gets, in the last-write-wins world, silence; in the CelinQ world, they get a conflict that was raised, attributed, and resolved on a specific date by a specific person, which is exactly the trace they came to find.

The use of tombstones deserves a mention in the same breath, because deletion is where naive history-keeping most often fails. When something is removed from a model, the tempting implementation is simply to make it disappear. But an auditor's most incisive questions are frequently about things that are no longer there. What happened to the system that used to be in scope? Why is there no longer a data flow to that external party? A record that handles deletion by erasure cannot answer these questions at all. By representing removals explicitly rather than by absence, the history retains the fact that something existed, when it stopped existing, and who ended it — and absence stops being ambiguous. The difference between "this was never modelled" and "this was modelled and then deliberately retired" is often the difference between a finding and a clean pass.

Having the answer before the question

The phrase in the standfirst — having the answer ready before they ask — is not rhetorical. The distinguishing feature of an organisation that handles audits well is not that it scrambles effectively when the request arrives. It is that the request requires no scramble, because the evidence was accumulating quietly the entire time. This is a much calmer way to live, and it changes the character of the audit itself. An audit conducted against a complete, ordered, attributed history is a matter of running queries and producing extracts. An audit conducted against a reconstructed history is a matter of interviews, apologies, and caveats, and every caveat invites another question.

There is a governance dimension that reinforces the historical one. CelinQ distinguishes roles — Viewer, Editor, Administrator, Owner — and supports change review before contributions become part of the shared model. This means that "was this change authorised" and "was this change reviewed" are not questions to be answered from memory. They are answered by the same records that hold the changes. When an auditor asks whether a particular sensitive part of the model can be altered by anyone who happens to have access, the answer is not a verbal assurance about how the team usually behaves. It is a demonstrable property of how the workspace is configured, backed by a history that shows the policy was actually in force during the period under review, not merely written down in a document nobody followed.

I want to be honest about the limits of this, because overstating it would be its own kind of audit risk. Tooling cannot make a badly modelled architecture into a well-modelled one, and it cannot supply judgement that was never exercised. If nobody ever classified a system correctly, no history will invent the classification. What the tooling can do is guarantee that whatever judgement was exercised is preserved faithfully, attributed honestly, and ordered correctly, so that the organisation gets full credit for the diligence it actually performed and is not penalised for diligence that was silently destroyed by the mechanics of sharing. That is a narrower claim than "CelinQ makes you audit-proof", and it is the true one. The value is not that the record is flattering. The value is that the record is real.

Sovereignty and the question of custody

For public-sector work there is a further consideration that sits underneath all of this, which is where the evidence physically lives and who controls it. An audit trail is only as trustworthy as the custody of the store that holds it. If the definitive history of a national or municipal architecture sits on infrastructure the organisation does not control, then the answer to "can this record have been altered" depends on a third party's practices, and that dependency is itself an audit finding waiting to happen. It also raises the harder question of whether the record can be produced at all, on demand, years later, without a commercial relationship intervening.

CelinQ is deliberately structured so that everything can stay under the organisation's own control. The shared workspace runs on a server the organisation operates. Storage is a database it already knows how to run and back up, whether SQLite for smaller deployments or PostgreSQL for larger ones. Transport between the architects' companions and the workspace is encrypted with certificate pinning, and access is authenticated with tokens, so the record in transit is protected without handing custody to anyone outside. The core of the product needs no external service to function. This is not incidental for a public body; it is often the precondition for using any tool at all, and it means the audit trail is genuinely the organisation's own, held on its own terms, producible on its own schedule.

The in-EA design assistant, which can generate content into a selected package and analyse existing parts of the model, is worth positioning correctly in this context precisely because it is the kind of capability that raises eyebrows in an audit. It is off by default, it operates within the organisation's control, and the core of CelinQ works entirely without it. That matters because an auditor's reasonable concern about automated generation of model content is whether it can be traced and reviewed like any other change — and it can, because anything the assistant produces enters the same attributed, reviewable history as a human edit. There is no separate, unaccountable path by which content appears in the model. Whatever the source, the record answers the same questions in the same way.

The reconstruction tax, and why it is paid twice

It is worth dwelling on the specific economics of reconstructing history under pressure, because the cost is routinely underestimated and it is paid in a currency organisations cannot easily spare. When an audit request arrives and the definitive history does not exist, someone has to build it. That someone is almost always a senior architect — the only person with enough context to piece the story together from backups, exported files, meeting notes, and their own memory. For the duration of the reconstruction, that architect is not doing architecture. They are doing forensic accounting on their own past work, and they are doing it against a deadline set by an external party who is watching how long it takes and drawing conclusions from the delay.

The tax is paid twice because the reconstruction is never fully trusted even after it is complete. An auditor knows that a history assembled after the fact, by an interested party, under time pressure, is exactly the kind of evidence that is most vulnerable to unconscious tidying. The story that emerges tends to be the story that reflects well on the team, not because anyone is dishonest but because memory reconstructs the past in a self-consistent way, and the gaps get filled with what should have happened rather than what did. The auditor discounts the reconstruction accordingly, which means the effort of building it buys less credibility than the same facts would have bought had they simply been recorded at the time. The organisation pays once to build the reconstruction and once more in the discount applied to it.

The hidden depth of the tax is that it recurs. An organisation that reconstructs its history once, for one audit, has not solved the problem for the next one; it has produced a document that itself ages, that captured only the questions asked that time, and that has to be redone from scratch when a different body asks different questions about a different period. Each reconstruction is bespoke to the request that prompted it, so none of the effort compounds, and a practice can find itself performing the same archaeology repeatedly, each time diverting the same senior people, each time producing evidence the next auditor will again discount. The work never accumulates into an asset because it was never a record in the first place — it was a series of one-off answers to one-off questions, and answers do not add up to a history.

A continuously accumulated history escapes both charges. There is no reconstruction to build, so no senior time is diverted into forensics, and there is nothing to discount, because the record was written contemporaneously by the ordinary act of saving work rather than assembled afterward by an interested party. The distinction between contemporaneous and reconstructed evidence is not a technicality to an auditor; it is close to the whole basis on which they decide what to believe. CelinQ produces contemporaneous evidence as a matter of course, because the history is a by-product of the work and not a separate deliverable that has to be curated. The organisation is spared the reconstruction tax entirely, and it is spared it precisely at the moments — a live incident, a formal inquiry, a change of leadership — when the tax would otherwise fall hardest and the capacity to pay it would be lowest.

A grounded takeaway

The practical advice that falls out of all this is unglamorous. If your architecture repository is a record that will one day be read as evidence — and in the public sector it almost certainly is — then the time to arrange for a defensible history is now, while nothing is being contested, rather than later, when something is. The cost of doing so is close to zero if the history accumulates as a by-product of ordinary work, and close to prohibitive if it has to be reconstructed under pressure from files and memories. The choice is really between paying a small, invisible cost continuously and paying a large, visible cost exactly when you can least afford it.

What CelinQ offers to that problem is not a promise that audits become pleasant, but a change in what an audit is made of. Instead of interviews and reconstructions, it is queries against a record that was true the whole time — complete, ordered, attributed, resistant to quiet alteration, and held on infrastructure the organisation controls. When the auditor finally asks who changed this, when, and on whose authority, the answer is already sitting in the workspace, exactly as it was on the day it happened. Having the answer before the question is not a matter of anticipation. It is a matter of having kept the record honestly from the beginning, and of using tooling that made keeping it honestly the path of least resistance rather than a discipline that had to be sustained by willpower against the grain of how the tools worked. That, in the end, is the only kind of audit readiness that survives contact with an actual audit.