Real-Time Collaboration Constraints: Keep Changes Traceable

Concurrent edits can overwrite one another unless the application checks what each writer is changing. For shared field records, we recommend treating conflict handling and change history as acceptance criteria, rather than assuming that a fast-updating screen establishes a reliable record.

Consider a proposed inspection app. One engineer changes an equipment condition while another corrects its location. Before choosing the collaboration library, decide whether both edits should survive, who can approve the result and what a later reviewer should see. This is a design exercise, not evidence that collaboration tools inevitably lose data.

Define what a save means

We would give the interface separate states for a change saved on the device, a change accepted by the server and a change awaiting resolution. Use those words in the requirements and test each transition. Do not label an unacknowledged upload as shared with the team.

That distinction follows the local-first approach described by Ink & Switch: users can modify local state offline, with changes synchronised when a connection becomes available. Local work and communication with other devices are separate operations. Our recommendation is to make the distinction visible wherever someone might act on the record.

For the inspection example, write down what the next engineer needs before starting work. Must they have the accepted revision, or may they proceed with a clearly marked local copy? Name the person who decides, and record the answer alongside the workflow. Avoid an unexplained green tick that leaves each user to interpret the state differently.

Conceptual illustration of offline work, not a diagram of the application's save or security controls.

Reject stale changes deliberately

HTTP's If-Match condition is designed to prevent accidental overwrites by parallel writers. A client can send an entity tag identifying the representation it read. The server compares that tag with the current representation before applying the request. If the condition is false, the server must not perform the requested method.

In our proposed app, require an update to carry the revision it was based on. If another engineer has already changed that revision, stop and show the difference rather than silently replacing their work. Ask the product owner whether the user should retry against the new revision or send the conflict to a supervisor.

Apply this rule to the server operation, not only the screen. Our acceptance test would submit two updates based on the same starting revision and inspect the stored result. Require the losing writer to receive an explicit outcome, and check that the interface preserves their proposed correction for review. These are requirements to demonstrate, not promises made by adding a header.

Choose merge rules around the field

Ink & Switch describes conflict-free replicated data types, or CRDTs, as a way to merge concurrent changes between devices. That provides a different option from rejecting every stale edit. We would still specify the meaning of a merged business record before adopting it.

For example, propose keeping independently added observations as separate entries. Treat two incompatible decisions about whether an inspection passed as a review case instead. Ask the responsible specialist to approve these examples before implementation. The software's chosen value should not be mistaken for an authorised operational decision.

There is also a difference between replicas catching up and a multi-step operation being repaired. In chapter 7 of Continuous Architecture in Practice, Erder, Pureur and Woods distinguish eventual consistency from compensation across related data changes. They explain that compensation does not provide the strong consistency of an ACID transaction.

For the proposed inspection workflow, we would therefore test the gap between recording an observation and creating its follow-up task. Decide what users should see if the second operation fails. Require a named recovery action instead of treating an eventual retry as proof that the whole workflow completed.

Preserve the explanation for the result

NIST's log-management guidance describes application requests and responses as useful for reconstructing event sequences and their apparent outcomes. It also warns that inadequately secured log sources are more susceptible to alteration. A history feature needs its own protection and review requirements.

We recommend recording the actor, record identifier, starting revision, proposed change and accepted result for this workflow. Link a supervisor's conflict decision to the competing proposals. Define correction and retention rules with the organisation rather than promising a permanent history of everything.

Ask the team to demonstrate the history using an ordinary user and an administrator. Can either change an earlier entry without leaving detectable evidence? Can a reviewer distinguish an attempted edit from an accepted one? Keep those answers with the test results. Do not describe the record as tamper-proof or legally sufficient on the strength of a database design alone.

Conceptual illustration of reviewing records, not evidence of audit completeness.

Prove the awkward sequence

Our suggested acceptance exercise uses two engineers editing the same record, an interrupted connection and a supervisor resolving the disagreement. Repeat it with a closed app and with a response that never reaches the sender. Compare each screen with the accepted record and its history.

Agree the expected result before running the exercise. Keep the observed result, the unresolved difference and the person responsible for correcting it. That gives the next delivery decision something specific to work from, without claiming that instant updates guarantee compliance.

Update, October 2026

For teams implementing these requirements with coding agents, our engineering article on independent review and tested delivery gates explains the delivery pattern. We recommend putting the stale-write and recovery scenarios into those gates, so a reviewer checks the agreed outcomes before the change is accepted.

Sources

• IETF, "HTTP Semantics", RFC 9110, section 13.1.1, 6 June 2022.
• Ink & Switch, "Local-first software: You own your data, in spite of the cloud", 1 April 2019.
• Murat Erder, Pierre Pureur and Eoin Woods, "Continuous Architecture in Practice", chapter 7, Addison-Wesley, 21 May 2021.
• NIST, "Guide to Computer Security Log Management", SP 800-92, 13 September 2006.
• Dendro Logic, "Closing the Loop to Full Autonomy", 17 July 2026. Cited only in the October 2026 update.