CelinQ Insights · No. 48

Preserving Offline Work After a Concurrent Delete: The CelinQ Rescue Zone

Building something new inside a package that someone else removes is a different shape of collision to editing something that gets deleted, and it needs a different answer.

An architect spends three days at a client site building out a new capability model underneath a package called Regional Operations. It is careful, substantial work: eight new elements, two supporting diagrams, a handful of connectors tying the new capabilities back into the existing landscape. The whole time, the laptop has no reliable connection back to the office, which is fine, because none of this depends on the network — the work happens against a local repository at full speed, exactly as described in the earlier piece on working offline and syncing later.

Back at head office, a portfolio rationalisation exercise concludes that Regional Operations as a package no longer reflects how the organisation is structured, and someone deletes it, intending for its now-obsolete contents to go with it. Nobody in that meeting has any way of knowing that a colleague is, at that very moment, three days into building something substantial inside the very package being removed. When the laptop finally reconnects, CelinQ has to reconcile a request to create eight new elements, two diagrams and several connectors, all nested under a parent package that the canonical workspace now says does not exist. This is not the same collision covered in the previous article in this pair. Nobody edited the same fact twice. The new work and the deletion are, strictly, about two entirely different things — and that is exactly what makes this case trickier, not easier.

A different shape of conflict

The resurrection problem covered previously is a collision over one entity: somebody deleted it, somebody else edited it, and the two sides disagree about whether it should exist. This situation has no such symmetry. The deleted package and the newly created elements are different entities entirely, connected only by the fact that the new elements declare the deleted package as their parent. There is no tombstone conflict to raise on any of the new elements individually, because none of them existed before the offline work began — from the server's point of view, they are pure creates, not edits to something it already knows about. But a create that names a deleted entity as its container is not an ordinary create either. It is a create with nowhere to go.

Why automatic deletion is unsafe

One tempting answer is to let the deletion cascade: if the parent package is gone, treat everything newly created underneath it as gone too, on the theory that the destination the architect intended no longer exists, so their work has nowhere sensible to land. This is unacceptable the moment you picture the actual person on the other end of it. Three days of careful, deliberate modelling work — new elements, diagrams, connectors, all the product of real thinking about how a capability landscape should look — would simply disappear, with no warning, the instant that laptop reconnects. The architect would not even receive a clear signal that anything had gone wrong; they would just notice, at some later point, that the work they remember doing is nowhere to be found. That is precisely the silent-loss failure mode this entire series of articles keeps returning to, and it is no more acceptable here than it was in the resurrection case. A person spent real hours producing this. A system that discards it because of a decision made in a completely unrelated meeting, without so much as flagging the collision, has failed at the one thing a collaboration tool exists to guarantee: that legitimate work does not vanish.

Why automatic resurrection is unsafe

The opposite instinct is just as tempting and just as wrong: since there is now new, apparently wanted work sitting under the deleted package, why not simply undelete the package to give it somewhere to live? This has an appealing symmetry — it seems to "rescue" the new work by restoring its home — but it silently reverses a decision that a governance process made deliberately and, in this scenario, correctly. Regional Operations was not deleted by accident; it was removed as part of a considered rationalisation exercise that the people back at head office are entitled to expect will actually take effect. Quietly reinstating a package because someone elsewhere happened to keep building inside it, unaware, would mean that offline work — through no fault of the person doing it — can override a deliberate architectural decision it never even knew existed. That is not a rescue. It is an accidental veto, exercised by someone who was not in the room and would probably be uncomfortable learning that their unrelated three days of modelling had that effect.

Neither "delete wins" nor "the new work wins" is actually a decision. Both are ways of avoiding one, and both happen to destroy something real in the process.

The Rescue Zone: neither deleted, nor resurrected

CelinQ's answer is to do neither automatically, and instead park the situation somewhere safe and visible until a person can look at it. Creating a child under a concurrently deleted parent raises what the Fusion engine calls a Rescue Zone capsule. The package stays deleted, exactly as the rationalisation exercise intended, so nobody's considered decision is silently reversed. The new work — every element, every diagram, every connector the offline architect built — is preserved completely intact inside the capsule, so none of it is silently discarded either. Nothing about the underlying disagreement is resolved automatically, because there genuinely is no automatic answer that respects both sides, but nothing is lost while the disagreement waits for someone to look at it. The system's job in this moment is not to guess correctly; it is to make sure that whichever way the eventual decision goes, it is made by a person with the full picture, not decided by accident through the order two unrelated changes happened to arrive in.

What "recoverable pending work" actually looks like

What a reviewer actually sees when a Rescue Zone capsule is opened is worth being concrete about, because the value of this mechanism lives entirely in how legible that view is. The capsule shows the deleted parent — what it was called, when it was removed, and by whom — alongside the complete structure of what was built underneath it: the new elements with their types and names, the diagrams that were created, the connectors that were drawn and what they link. This is not a cryptic reference to "8 orphaned objects." It is the actual content, laid out clearly enough that a reviewer who was not part of either the rationalisation meeting or the three days of offline modelling can understand, in a few minutes, exactly what happened and what is at stake in the decision ahead of them.

Resolving the capsule: four honest options

Once a person reviews a Rescue Zone capsule, CelinQ offers a small set of resolutions rather than an open-ended text field, because a bounded set of well-understood outcomes is easier to reason about correctly under time pressure than a blank canvas. The reviewer can accept the deletion as final and let the new work be removed along with its intended home, which is the right call if the rationalisation genuinely makes the new capability model obsolete too, or if it belongs somewhere else entirely and was only ever placed here provisionally. The reviewer can restore the deleted package with the new work applied on top of it, which is the right call when the deletion turns out to have been premature or the new work is exactly the reason the package should have survived. The reviewer can move the surviving work to a different, still-existing package, which is often the most realistic answer in practice: the rationalisation was correct, Regional Operations genuinely should go, but the new capability elements are good work that deserves a home elsewhere in the tree rather than being deleted along with a package it merely happened to be created inside. Or the reviewer can restore the new work as an entirely new package of its own, giving the offline architect's contribution a clean, independent identity rather than reattaching it to something the rest of the organisation has already decided to retire.

What all four resolutions share is that none of them happens without someone actually looking at the evidence and choosing. The deletion is respected by default only in the narrow, honest sense that the canonical state does not change until a decision is made — it is not respected in the sense of quietly winning by default while the new work is thrown away unseen.

Why not just park it somewhere automatically

There is a fifth option that sounds appealing at first and turns out to be a trap: automatically move any orphaned create into some default holding package — a Recovered Items folder, say — so that nothing is ever left dangling and no human has to intervene at all. This would remove the friction entirely, and it is worth explaining precisely why CelinQ does not do it. Moving the new work anywhere, even somewhere deliberately neutral, is still a structural decision about the model, and it is one the system has no basis for making well. A Recovered Items package that quietly accumulates the debris of every reorganisation becomes, over time, exactly the kind of directionless catch-all that good model hygiene exists to prevent — the architectural equivalent of a shared drive's Misc folder, growing forever, trusted by nobody. Worse, an automatic move still changes the canonical model without anyone having actually reviewed what moved or why, which reintroduces the very silent-decision problem this whole mechanism is designed to avoid, just with a friendlier-sounding destination. The honest position is that "where does this work belong now" is a question about the architecture, not a question about data safety, and only the first kind of question has an automatic answer worth trusting.

Why the local work was never blocked in the first place

Something notable did not happen anywhere in this story: at no point did the offline architect's local Enterprise Architect repository refuse to let them build inside Regional Operations, or warn them that the package might not be safe to build under, or ask them to check with anyone first. This is a direct consequence of the local-first design covered throughout this series. The architect's local repository has no way of knowing, in real time, what is happening on a canonical workspace it cannot currently reach, and a system that tried to guess — refusing to let you create anything under a package it could not confirm still existed — would reintroduce exactly the kind of dependency on live connectivity that local-first modelling exists to remove. The alternative design, familiar from the shared-repository locking model covered earlier in this series, would be to require a live check-out before creating anything, which solves this particular collision by preventing the offline work from happening at all. That is not a solution CelinQ is willing to accept, because it throws away the three days of good work along with the collision risk. The correct trade is not to prevent the situation from arising — it is to make sure that when it does arise, nothing is lost and nobody's decision is silently overridden. Rescue Zone is that trade, made explicit.

A worked example: what the capsule actually contains

Concretely, when the offline architect's laptop reconnects and pushes its accumulated ChangeSet, the pipeline processes each new entity in turn. For the first new element, it looks up the declared parent by stable identity and finds a tombstone rather than a live package. That single fact — create against a tombstoned parent — is what routes the entity into a Rescue Zone capsule rather than a normal create. The capsule records the parent's identity and deletion revision, the new element's full proposed state exactly as the offline architect built it, and a reference back to the ChangeSet and revision the create was part of. The same happens for the second new element, the diagrams, and the connectors, each evaluated against the same tombstoned parent. Because none of these new entities existed anywhere in the canonical workspace before this push, there is no base version to compare against and no possibility of a "silent update" masquerading as a create — the pipeline can be completely certain that what it is looking at is new work meeting a deletion, not an edit meeting a deletion, which is precisely the distinction that separates this article from the previous one. Nothing is applied to the canonical state until a reviewer opens the capsule, and until that happens, both the deletion and the new work sit safely, side by side, each fully intact.

Root-cause grouping, in miniature

A single deletion like this one rarely produces just one loose thread. If the offline architect's three days of work touched several distinct new elements, several connectors and a couple of diagrams, each of those pieces individually collides with the same deleted parent, and today each one is classified and evidence-bundled on its own terms rather than folded into a single umbrella decision. In practice this means a reviewer working through a Rescue Zone situation of any real size is looking at more than one capsule, not one — a genuinely useful but currently unglamorous fact worth stating plainly rather than glossing over. What does help is that every one of those capsules, however many there are, points back to the exact same root cause: the same deleted package, the same timing, the same underlying story. A reviewer scanning the list can see that pattern immediately, because the evidence in each capsule names the same parent, even though resolving all of them today is still a series of individual decisions rather than a single bulk action. The question of how to compress a cascade like this into fewer, more efficient decisions — and how much of that compression is already achieved simply by not raising a capsule for anything that was never actually in dispute — is the subject of the next article in this series.

No silent loss, as a standing guarantee

This mechanism connects back to the broader promise the whole approach to reconciliation rests on. CelinQ's Fusion benchmark — a hundred thousand operations pushed through the real store and merge pipeline by five concurrent simulated clients, seeded and fully reproducible — is built specifically to catch exactly this class of failure, among others: any silent loss of work, anywhere in the run, is treated as a hard failure of the test itself, not a statistic to be minimised. A Rescue Zone capsule is one of the concrete mechanisms that makes that guarantee possible for this specific, tricky shape of collision. It would be easy to build a system that looked correct in the common case and quietly dropped orphaned creates under load; making sure that never happens, and proving it under a large, adversarial, reproducible run rather than merely asserting it, is what the guarantee is actually worth.

Audit and traceability

Every Rescue Zone capsule, and every resolution applied to it, becomes a permanent part of the workspace's ordered revision history in the same way any other change does. This matters for the same reason it mattered in the resurrection case discussed previously, and it matters for a second reason specific to this scenario: rescued work often represents genuine new architectural thinking, and an organisation with any seriousness about traceability needs to be able to show, months later, exactly where a given package came from — whether it was rescued from underneath a deletion, restored to its original parent, or deliberately allowed to be removed along with work that turned out not to be needed after all. None of that history is available if the collision was resolved silently by a rule rather than a recorded human decision.

The honest limits

This mechanism, like the tombstone logic it sits alongside, buys safety at the cost of some friction, and it is worth being direct about where that friction shows up. A large reorganisation that deletes several packages while several colleagues are simultaneously working offline in unrelated parts of the tree can generate a genuine cluster of Rescue Zone capsules in a short window, and today resolving that cluster is a series of individual reviews rather than one consolidated decision, even when every capsule in the cluster shares the same obvious answer. Teams planning a significant restructuring while people are travelling should expect this and budget a little review time for it afterwards, the same way they would budget time to review any other batch of pending approvals. There is also a structural limit worth naming plainly: concurrency in the current engine is resolved pairwise against the canonical head as pushes arrive, not as a single simultaneous many-way comparison, so a Rescue Zone situation touched by more than two people's offline work in the same window is still handled correctly — nothing is lost, nothing is silently applied — but it may surface as more than one round of capsules rather than a single tidy batch.

None of that changes the underlying guarantee, which is the part that actually matters when real work is at stake. A deletion that should have happened is never silently blocked by unrelated offline work nobody knew about, and offline work that took real time and real judgement is never silently discarded because of a decision made somewhere else entirely. The friction is a person occasionally having to look at a capsule and make a call. The alternative — a system confident enough to guess on its own, in either direction — is the one actually worth worrying about.

It is also worth being honest about a softer limit that has nothing to do with the engine and everything to do with organisational habits: a Rescue Zone capsule is only as useful as the review discipline around it. A workspace where capsules are left open for weeks because nobody owns the job of triaging them gets none of the benefit of the mechanism and all of the friction, because the new work sits unresolved, technically preserved but practically unusable, until someone finally looks. CelinQ's Control Plane surfaces open capsules plainly rather than burying them, but a tool can only make a decision visible; it cannot make an organisation decide promptly. Teams that get real value from this mechanism tend to be the ones that treat an open capsule the way they would treat an open pull request — something with an owner and an expectation of timely review — rather than a queue that quietly grows in a tab nobody opens.