CelinQ Insights · No. 04

Who changed what, and why: giving your model a memory

A model without history is a model no one fully trusts. Building an honest record.

There is a particular kind of meeting that anyone who has maintained a shared architecture repository for more than a year will recognise. Someone opens a diagram in front of the room, points at an element that should not be there, or a relationship that has quietly reversed direction, or a stereotype that no longer matches the convention the team agreed on eighteen months ago, and asks the only question that matters: when did this happen, and who did it? The room goes quiet. People look at their own screens. Somebody suggests checking the last backup, then remembers the backups are full snapshots taken nightly, so the best anyone can offer is that the change appeared sometime between two Tuesdays. Nobody can say why. The person who made the edit may have left the organisation, or may simply not remember, because to them it was a routine tidy-up on an ordinary afternoon that they have long since forgotten.

This is what a model without a memory feels like from the inside. It is not dramatic. Nothing has crashed, no data has been visibly lost, the file still opens and the diagrams still render. What has been lost is something quieter and, in the long run, more expensive: the ability to account for the model's own state. And an architecture model that cannot account for itself is a model that slowly stops being believed.

Why the record goes missing in the first place

It is worth being precise about why shared repositories so often end up with no usable history, because the reasons are structural rather than a matter of anyone being careless. A model held in a single project file, whether that file lives on a network share or inside a shared database repository, records the present state of the model very well and the past not at all. The file is the model. When you save, the previous state is simply overwritten by the new one. There is no seam between what the model was yesterday and what it is today, because the storage format was designed to hold one coherent picture, not a sequence of pictures over time.

Teams intuitively feel this gap and reach for the tools nearest to hand. The most common is the nightly backup: a copy of the whole repository, filed by date, sitting in a folder that grows without limit. This is genuinely better than nothing, and more than one afternoon of work has been rescued from it. But a backup is a photograph of the entire model at a moment in time, and answering a question about a single element from a shelf of photographs is a forensic exercise. You have to guess roughly when the change occurred, open an old copy, find the element, compare it by eye to a newer copy, and repeat until you have bracketed the change to a day. Even when it works, it tells you what changed and roughly when. It almost never tells you who, and it never tells you why.

The second common reaction is to graft the record onto the model by hand. A tagged value called last modified by, a notes field where people are asked to jot what they did, a naming convention on baselines. These conventions depend entirely on discipline, and discipline is exactly the resource that runs short when a deadline is close and someone is making a dozen small corrections in a hurry. The fields that most need to be filled in are the ones filled in least, because the busy, consequential edits are the ones made under pressure. So the manual record is most reliable for trivial changes and least reliable for the ones you will actually want to investigate later.

A shared database repository improves the concurrency story — several people can be connected at once — but it does not, by itself, give you a narrative of change. It holds the current rows. Unless something is deliberately capturing every transition and attributing it, the database is just a more sophisticated way of storing the same single present-tense picture. The memory problem is not a symptom of using the wrong storage. It is a symptom of storing state without storing the story of how the state came to be.

What the missing memory actually costs

The cost is easy to underestimate because it does not show up as a line item. It shows up as friction, hesitation, and a slow erosion of trust, spread across many small moments.

Consider the reviewer's problem. An architecture practice that takes governance seriously wants someone to look at changes before they become part of the accepted model. But review is only possible if you can see the change as a change — this element was added, this attribute went from one value to another, this relationship was removed. If all you can see is the new state of a large model, review degenerates into re-reading the whole thing and hoping you notice what moved. Nobody has time for that, so review either does not happen or happens as a rubber stamp. The absence of a change record does not just make history hard to reconstruct after the fact; it makes governance impossible in the present, because governance is fundamentally the act of examining a change before accepting it.

Consider the trust problem. When a stakeholder from outside the architecture team — a project manager, an auditor, a security officer — asks why the model shows a particular integration, the architect wants to be able to answer with something better than a shrug. Ideally the answer is a small, honest story: this was added during the such-and-such project, by this contributor, and here is the note explaining the decision. When that story is unavailable, the architect is reduced to reasoning about the model as if it were a natural object to be interpreted, rather than an artefact that people made on purpose for reasons they could once have stated. Over time, stakeholders learn that the model cannot explain itself, and they start treating it as decoration rather than as a source of truth. The moment people stop trusting that the model reflects deliberate decisions, they stop consulting it, and an unconsulted model decays quickly.

Consider the recovery problem. Someone makes a well-intentioned but wrong edit — restructures a package, deletes elements they believed were obsolete, applies a bulk change that turns out to have caught elements it should not have. Without a record, the team cannot cleanly answer what the model looked like before, cannot isolate exactly what that person touched, and cannot undo their work without also undoing everyone else's from the same period. The absence of history turns a small, reversible mistake into a permanent scar, because the only tool for reversal is the blunt instrument of restoring an entire old backup and losing everything else that happened since.

A model that cannot say who changed what, and when, and ideally why, is a model that quietly asks everyone to take its current state on faith. Faith is not a foundation you want under a decision that costs real money.

What an honest record actually requires

If the diagnosis is that we store state without storing the story of change, the remedy is to make change itself a first-class thing the system records, automatically, without depending on anyone's discipline. That sounds obvious once stated, but there are a few properties that separate a record worth having from a record that merely exists.

The first is that it must be complete and automatic. A history that depends on people remembering to annotate their work is a history with holes exactly where the interesting edits are. The record has to be produced as a by-product of ordinary work — you edit, you save, and the fact of that change is captured with no additional ceremony. If keeping the record costs the architect anything at the moment of editing, it will erode under pressure, and the erosion will be selective in the worst possible way.

The second property is that it must be at the right level of detail. A record that says only "the model changed on Thursday" is barely better than a backup. A useful record works at the level of individual model facts: this specific element gained this attribute, this relationship was created between these two elements, this element was deleted. When the unit of history matches the unit of meaning in the model, you can ask precise questions and get precise answers, and you can show a reviewer exactly the delta rather than the whole landscape.

The third property is attribution. Every change should carry the identity of the person who made it. This is not about blame; it is about being able to ask a knowledgeable human. When you can see that a particular contributor made a change, you know who to talk to, and half the time the conversation is simply "oh yes, that was for the migration project, here's the context." Attribution turns the model into something that remembers not just what happened but who to ask about it.

The fourth property is order. It is not enough to know that two changes happened; you need to know which came first, because architecture is full of edits that only make sense in sequence. An element is created, then wired into its neighbours, then refined; a relationship is added, then later redirected. A complete, ordered history lets you replay the evolution of a part of the model and understand not just its current shape but the path it took to get there. Ordering is also what makes clean reversal possible, because to undo something safely you have to know precisely where in the sequence it sat and what came after it.

How CelinQ approaches it

CelinQ was built local-first, which turns out to matter a great deal for history. Each architect works in their own local repository, at full speed, and a background companion service notices every save. Because the system is watching saves as they happen rather than diffing whole files after the fact, it can capture change at the level of individual model facts and attribute each one to the person who made it. The unit of history is the same as the unit of meaning: an element, an attribute, a relationship, a deletion. That is what allows the record to answer precise questions instead of vague ones.

The result is a complete, ordered revision history of the shared workspace. Not a shelf of nightly photographs, but an actual sequence of attributed changes that you can read in order. When someone points at a suspicious element in a meeting, the question "when did this happen and who did it" stops being a forensic exercise and becomes a lookup. You can see the change, see the contributor, and see where it sits in the timeline relative to everything around it.

This is also what makes CelinQ's approach to merging honest, and the two features are more connected than they first appear. The merge engine, CelinQ Fusion, reconciles the work of different architects deterministically at the level of individual facts, and it treats deletions explicitly rather than letting them vanish silently — a deleted fact leaves a marker behind so the system knows the absence was intentional, not an accident of merging. A record built on the same fact-level foundation can therefore represent a deletion as a real event with an author and a place in the sequence, instead of a hole that appears in the model with no explanation. The history does not just tell you what was added; it can honestly account for what was removed, and by whom.

Because every change is attributed and ordered, review becomes possible as a normal part of the workflow rather than an aspiration. A change can be examined as a change before it is accepted into the shared model, which is what governance actually means in practice. And because the history is complete rather than sampled, recovering from a bad edit no longer requires the blunt instrument of restoring a whole old copy. You can see precisely what a particular contributor touched, in what order, and deal with it surgically.

The honesty of preserving conflict

There is a subtle but important dimension to an honest record that deserves its own attention, because it is where many systems quietly cheat. When two people change the same thing in incompatible ways, the tempting shortcut is to pick a winner — usually whoever saved last — and let the other change disappear. This produces a clean-looking model and a dishonest history. The record shows one change and no trace of the other, so the model's memory now contains a lie by omission: it claims a decision was made cleanly when in fact two people disagreed and one of them was silently overruled.

CelinQ refuses this shortcut. Genuine conflicts are not resolved by fiat; they are preserved and surfaced for a human to settle deliberately. This matters for the record because it means the history reflects what really happened, including the moments where two contributors pulled in different directions. When you look back at how a contested part of the model reached its current shape, you can see that there was a conflict and that it was resolved by a person making a choice, rather than by a rule quietly discarding half the work. A model's memory is only worth having if it is honest, and honesty includes remembering the disagreements, not just the tidy consensus that emerged afterward.

What changes when the model can remember

It is easy to describe history as a compliance feature — the thing you switch on because an auditor might one day ask. That framing undersells it. The deeper change is in how the team relates to its own work.

When the record is complete and automatic, architects stop hedging. They make the tidy-up edit they have been putting off, because they know it is reversible and accountable rather than a permanent, untraceable alteration. They delete the genuinely obsolete element instead of leaving it in place out of fear, because the deletion is recorded as a deliberate act rather than a mystery someone will later have to reverse-engineer. The presence of a memory makes people braver about maintaining the model well, which is exactly the behaviour you want and exactly the behaviour that an untrustworthy, unaccountable repository suppresses.

When change can be reviewed, the practice develops a rhythm where quality is checked continuously in small increments rather than in one dreaded audit at the end of a project. When work is attributed, knowledge does not walk out the door with the person who leaves, because their reasoning is at least partly captured in the record and, where they left a note, in their own words. When the sequence is preserved, the model becomes teachable: a new architect can read how a section evolved and understand the intent behind its current shape, rather than inheriting a static picture they have to reverse-engineer.

None of this requires the architect to work differently. That is the part worth emphasising to a skeptical reader who has been promised frictionless governance before and found it came with a tax on every edit. In a local-first arrangement, each person keeps editing their own repository at native speed, online or offline, and the record accrues quietly in the background as saves are detected and synchronised. The memory is a by-product of ordinary work, not an extra chore bolted onto it. You do not fill in a form; you do not remember to annotate; you do not pause to snapshot. You model, and the account of your modelling writes itself.

History as the backbone of governance and audit

There is a family of requirements that arrives, sooner or later, in any serious architecture practice, and especially in public-sector and regulated work: the demand to demonstrate control over the model rather than merely possess it. An auditor does not want to be told that the architecture is well managed; they want evidence. A governance board does not want assurances that changes are considered; they want to see that a change was reviewed and by whom. A security review does not want a promise that nothing untoward was slipped into the model; it wants a record it can inspect. All of these are, at bottom, requests to the model's memory. If the memory is missing, every one of them becomes an exercise in reconstruction and apology.

A complete, ordered, attributed history answers this whole family of demands with the same underlying capability, which is why it is worth treating history as foundational rather than as one feature among many. When you can produce, on request, an account of what changed, in what order, and at whose hand, you are no longer scrambling to assemble evidence after the fact from backups and memory. The evidence was accruing all along, as a by-product of ordinary work. The difference between a practice that can answer an auditor calmly and one that dreads the question is very often not diligence — the diligent team may simply lack the tooling to have kept the record — but whether the tool captured the story automatically or left it to human discipline that inevitably frayed.

CelinQ layers roles and change review on top of the same fact-level history, so the record is not only a passive account you can read after the fact but an active part of how change is admitted to the shared model in the first place. A change can be examined before it is accepted, by someone whose role gives them that responsibility, and the fact of that examination becomes part of the record too. The distinction between viewing, editing, administering, and owning the workspace means the history can honestly show not just who changed the model but who was entitled to, which is precisely the kind of thing a governance review exists to confirm. History and governance are not two separate concerns bolted together; they are the same concern seen from two angles, and building both on the same fact-level foundation is what keeps them coherent.

A grounded takeaway

The question that opens the awkward meeting — when did this happen, and who did it, and why — is not really a question about a single suspicious element. It is a question about whether the model is a trustworthy account of deliberate decisions or merely the accumulated residue of edits nobody can explain. A repository that stores only its present state can never answer it, no matter how disciplined the team tries to be, because the answer lives in the transitions and the transitions were never kept.

Giving a model a memory means capturing change as a first-class thing: complete, automatic, at the level of individual facts, attributed to a person, kept in order, and honest enough to remember conflicts as well as consensus. Do that, and the awkward meeting stops happening. Someone points at the element, you look it up, and the model tells you the story. Trust follows from there, and a trusted model is the one people actually use to make decisions — which was, presumably, the whole point of building it. That is the outcome CelinQ is built to make ordinary rather than exceptional, and it does so while leaving every architect free to work exactly as they already do, alongside Sparx Enterprise Architect rather than in place of it.