CelinQ Insights · No. 03

Nobody should lose an afternoon's modelling to a save collision

The quiet ways work disappears in shared repositories, and how to make loss impossible.

The worst thing about losing work is not the work. It is the doubt. An architect who has lost an afternoon's modelling to a save collision does not just lose the diagrams and relationships they built; they lose their confidence that the model reflects what they did. Once you have seen your work vanish without explanation, you start saving defensively, exporting private copies, taking screenshots of diagrams before you close them, keeping a running note of what you changed in case you have to prove it later. The loss of trust outlasts the loss of the afternoon by months, and it changes how the whole team behaves toward the tool that is supposed to be helping them.

This article is about the specific ways work disappears in shared modelling repositories, and about what it would take to make that disappearance genuinely impossible rather than merely unlikely. The distinction matters more than it might seem. A great deal of the reassurance offered around collaborative tools amounts to "this rarely happens," which is precisely the wrong kind of comfort, because rare silent loss is more dangerous than frequent loud loss. If it happened often, you would never trust the tool and you would protect yourself. Because it happens rarely, you relax, and the one time it does happen it catches you with your guard down.

The anatomy of a vanished afternoon

Work does not usually disappear dramatically. There is rarely a crash or an error. It goes quietly, and it goes in a small number of recognisable ways, each of which feels, in the moment, like nothing unusual happened at all.

The most common is the overwrite. Two people work from the same starting point, both save, and a system that resolves collisions by keeping the most recent write simply keeps one save and discards the other. The person whose work was discarded gets no signal. Their save appeared to succeed; the application reported no problem; they closed the model believing their afternoon was safe. It was not, but they will not learn that until they next go looking for something they know they made and cannot find. And because human memory is fallible, the first reaction is usually self-doubt rather than suspicion of the tool. Did I actually draw that relationship, or did I only mean to? That uncertainty is corrosive precisely because it points the blame inward.

A second way is the failed reconciliation of a private copy. An architect working offline, or simply preferring the speed of a local file, keeps their own copy and intends to fold their changes back into the shared model later. When later comes, the shared model has moved on, and the reconciliation is done by hand, under time pressure, by a tired person comparing two large models by eye. Things get missed. A relationship here, a documentation change there, a whole diagram that was on a branch of the tree the person forgot to check. The losses are real but they are attributed to human error rather than to the fact that the tool offered no safe way to do the thing everyone needed to do, and so the underlying cause is never addressed.

A third way is subtler and often goes entirely unrecognised: the accidental resurrection or accidental deletion that comes from a merge that does not understand deletions. One person removes something obsolete; another, unaware, keeps working with it; the two saves meet; and depending on how the collision is resolved, either the deletion is undone and a dead element quietly returns to the model, or an edit is discarded along with it. Nobody experiences this as "losing work" in the moment, because no error appears, but the model now says something nobody decided it should say. That is loss too, even if it takes a different shape from a vanished diagram.

Lost work rarely announces itself. It shows up later as a relationship you are sure you drew, an element you are sure you deleted, a diagram that is somehow half of what you remember building. By then you cannot prove anything, and the doubt is the real damage.

Why "be careful" is not a fix

Faced with these failure modes, the usual organisational response is procedural. Take locks. Announce when you are working in a shared area. Save often. Keep backups. Communicate. Do a careful reconciliation. All of this is sensible advice and all of it shares the same fatal weakness: it puts the burden of preventing data loss on human vigilance, and human vigilance is exactly the thing that does not scale and does not survive a busy afternoon.

People forget to take locks. People forget to release them. People are in a hurry, or in a workshop, or offline, or simply concentrating on the modelling rather than on the ceremony around the modelling. A safety system that only works when everyone is careful all the time is not a safety system; it is a way of relocating the blame for the inevitable failure onto whoever was least careful on the day. The whole point of engineering a system properly is to make the safe path the default path, so that doing the ordinary thing is automatically the safe thing, and no amount of hurry or distraction can produce silent loss.

So the right question is not "how do we get people to be more careful," which has been the answer for years and has not worked. The right question is "what would a system look like in which losing work to a save collision is not a rare misfortune to be guarded against but a structurally impossible outcome." That is a higher bar, and it is the bar worth aiming at.

What unites all three of these failure modes is that the tool made a decision on the architect's behalf and then said nothing about it. The overwrite decided which save to keep. The hand reconciliation forced a tired person to make dozens of decisions with no help and no record. The deletion-blind merge decided whether a removal stood or fell. In every case a choice was made, and in every case the person affected was not told that a choice had even occurred, let alone which way it went. That silence is the common thread, and it is the thing that has to be attacked, because a loss you are told about is a problem you can fix, while a loss you are not told about is a problem that fixes you.

Making loss structurally impossible

Impossibility is a strong word, so let us be precise about what it requires and where its edges are. To make save-collision loss structurally impossible, a system has to guarantee a small number of things at the level of its design, not as best-effort behaviour but as invariants.

It has to treat every architect's local work as the primary copy, edited at full speed whether online or offline, so that nobody is ever pushed into keeping an unsafe private copy in order to get their job done. The moment people are forced off the supported path to work the way they need to, the safety guarantees evaporate, because the tool is no longer in the loop for the work that matters most. CelinQ is local-first for exactly this reason: your own repository is where you work, always available, never waiting on a network, and the tool is present for every change you make rather than only for the ones you remember to bring back.

It has to capture your changes reliably as you make them. A background companion service watches for each save and synchronises your work into a shared workspace running on the organisation's own infrastructure. Because this happens automatically on save rather than as a manual step you have to remember, there is no moment where your afternoon exists only in your head or only on a branch you forgot to reconcile. The capture is not something you do; it is something that happens, which is the only kind of safety that survives a distracted human.

It has to combine parallel work without discarding any of it, which means merging at the level of individual model facts using a deterministic three-way merge against the common ancestor, so that everything two people did in parallel is kept whenever their changes do not genuinely conflict. This is CelinQ Fusion, and its defining refusal is the refusal to ever resolve a collision by keeping one save and throwing the other away. There is no "last write wins" anywhere in it, because that rule is precisely the mechanism by which afternoons vanish.

It has to handle deletion as a deliberate, recorded act rather than as the mere absence of something, so that removals are never silently undone and edits are never silently dragged into a deletion. Fusion does this with explicit deletion markers, tombstones, that let the merge tell the difference between "this was removed on purpose" and "this was never here," which is the distinction that naive systems get wrong and that quietly corrupts models over time.

And it has to preserve genuine conflicts rather than resolving them by guessing. When two people really have changed the same fact incompatibly, the system isolates that conflict, keeps both sides, and surfaces it for a person to decide, while the surrounding non-conflicting work merges cleanly. A genuine conflict raised for a human decision is not lost work. It is the opposite: it is the system refusing to lose either side by pretending there was no disagreement.

Put those invariants together and the space in which silent loss could occur closes up. Your work is captured automatically, not by an act of memory. Parallel work is combined rather than overwritten. Deletions are honoured rather than guessed at. Real conflicts are held open for a person rather than resolved by timing. There is no remaining step at which an afternoon can quietly evaporate, because every step that used to discard something now either keeps it or shows it to someone.

There is a useful way to think about the difference between "unlikely" and "impossible" here. A system that makes loss unlikely is one that has fewer of the events that cause loss; it still has them, just not as often, and every one of them is a silent catastrophe waiting for the wrong afternoon. A system that makes loss structurally impossible is one where the events that cause loss have been removed as categories, not reduced as frequencies. There is no overwrite because nothing is ever overwritten. There is no dangerous hand reconciliation because the reconciliation is automatic and fact-level. There is no deletion-blind merge because deletions are recorded and reasoned about. There is no silent conflict resolution because conflicts are surfaced. You are not lowering the odds of a bad event; you are ensuring the bad event has no mechanism by which to occur. That is a categorically stronger position, and it is the only one that actually earns an architect's trust, because trust cannot be built on "it probably will not happen to you."

How this feels in ordinary use

None of this should be experienced as ceremony, and that is part of the design. The architect does not run a merge, does not manage synchronisation, does not think about tombstones or ancestors or any of the machinery described here. They model. They save. Their work is captured. When a colleague's parallel work exists, it is simply there alongside theirs, combined, with nothing to do. On the rare occasion that a genuine conflict arises, it is raised clearly, with both versions visible, as a small and contained decision rather than a crisis. The whole apparatus of safety runs underneath the ordinary act of modelling, which is exactly where safety machinery belongs. If people had to think about it, they would forget to, and the forgetting is where loss lived in the first place.

The presence of other people is visible in a light way too. You can see who else is active in the workspace, which restores something the shared-file model never really offered: an awareness of your colleagues as collaborators rather than as competitors for a lock. In the old world, knowing someone else was in the model was a warning; it meant contention and waiting. Here it is simply information, and often reassurance, because their being there costs you nothing and their work will combine with yours. The social texture of collaboration changes when the tool stops making your colleagues into obstacles.

The history that lets you sleep

There is one more piece, and it addresses the doubt as much as the data. Every workspace keeps a complete, ordered revision history. This changes the emotional character of the whole thing, not only its technical soundness. In a system with no reliable history, the fear of loss is rational, because if something did go missing you would have no way to recover it or even to confirm it was ever there. In a system where every change is recorded in order, that fear loses its foundation. If a question ever arises about how the model reached its current state, the history answers it. If something genuinely needs to be recovered, there is a record to recover it from.

This is why the history is not a compliance afterthought but a core part of what makes the system trustworthy day to day. Combined with clear roles that determine who can do what, review and governance over changes, and lightweight presence so you can see who else is active in the workspace, it means an architect can work without the low background anxiety that a shared repository so often produces. You are no longer keeping private screenshots as insurance. You are no longer maintaining a running note of your own changes in case you have to prove them. The system remembers, in order, faithfully, and you can go and look whenever you want to. The defensive habits fall away because the thing they were defending against can no longer happen.

The honest edges

It is worth being precise about what "impossible" does and does not cover, because overclaiming here would undermine exactly the trust the whole approach is trying to build. Making save-collision loss structurally impossible means that the ordinary act of two or more people modelling in parallel and saving cannot silently discard anyone's work. It does not mean that a person cannot make a modelling mistake, delete something they later wish they had kept, or resolve a genuine conflict in a way they later reconsider. Those are human decisions, and the system's job is not to prevent decisions but to make sure they are decisions, made by a person who can see what they are choosing between, rather than accidents inflicted by the tool. When a person does reconsider, the ordered history is there to make the reversal possible, which is the right kind of safety net: it catches judgement, not just mechanics.

It also depends, as any serious system does, on the organisation running its side properly. The shared workspace lives on infrastructure the organisation controls, on-premises or in its own cloud, with encrypted transport, certificate pinning, and token authentication protecting it, and with storage in SQLite for small teams or PostgreSQL for larger deployments. The sovereignty this provides is a genuine strength; the core collaboration needs no external service, and everything can stay under the organisation's own control. But sovereignty comes with the ordinary responsibility of looking after a server, and it would be dishonest to pretend that responsibility away. The optional in-EA design assistant, which can generate content into a selected package or analyse existing parts of the model, is off by default and equally sovereign, and the entire collaboration and safety story stands with it disabled. The point is that the safety guarantees rest on the collaboration engine, not on any optional extra.

And, once more, none of this replaces Enterprise Architect. Each architect keeps modelling in EA, in their own local repository, at full speed. What CelinQ removes is not the tool anyone knows but the specific, recurring, morale-sapping event in which an afternoon of that modelling disappears because two saves collided and one of them was quietly chosen to lose.

What it is worth

The direct cost of a lost afternoon is easy to name: the hours it takes to redo the work, assuming the person even realises it is gone and can remember what they did. But the direct cost is the smaller half. The larger half is the defensive tax the whole team pays forever afterward, the private copies and the screenshots and the running notes and the low, persistent unwillingness to fully trust the shared model. That tax is paid every single day, by everyone, in small increments, and it never shows up as an incident because it is not an incident; it is a permanent adjustment to how carefully and how slowly people work.

It is worth noticing how much of that tax is invisible to the people paying it. Nobody budgets time for keeping screenshots or for the slight hesitation before a big change or for the private export made "just in case." These are habits, not line items, and habits do not appear in any accounting of what the tool costs. Yet in aggregate they are one of the largest costs a shared modelling environment imposes, precisely because they are borne quietly, by everyone, every day, and never questioned. A team that has lived with an unsafe repository for long enough often cannot even see the defensive tax any more, because it has become simply how one works. It only becomes visible in the contrast, when the loss becomes impossible and the habits, no longer needed, slowly fall away and people realise how much effort they had been spending on self-protection.

Remove the possibility of silent loss and you do not just save the occasional redone afternoon. You retire the defensive tax. People stop protecting themselves against the tool and start trusting it, and a team that trusts its shared model works faster, more openly, and with far less friction than one that is quietly braced for the next disappearance. Nobody should lose an afternoon's modelling to a save collision, and the reason to insist on it is not only the afternoon. It is everything the fear of that afternoon costs the team for the rest of the year.