Two Crews, One Asset, Two Different Answers
Offline work creates data conflicts. Crew A fixes the pump. Crew B logs it as broken. Who is right? We need conflict resolution that respects the timeline.
The Ghost in the Machine
It happened on a pipeline maintenance job. Tuesday morning. Crew A went to Mile Marker 40. They replaced a pressure sensor. They marked the asset “Operational” on their tablet. They were offline.
Tuesday afternoon. The Maintenance Planner in the office looked at his screen. He saw Mile Marker 40 was “Defective” (old data). He updated the record to add a note: “Order new parts.”
Tuesday evening. Crew A returned to base. Their tablet synced. The system saw two changes.
- Crew A: “Operational.”
- Planner: “Order parts.”
The system was set to “Last Write Wins.” The Planner had saved his note at 2:00 PM. Crew A synced at 5:00 PM. But the system looked at the sync time, not the work time. Or sometimes it just gets confused.
The result? The system overwrote the Planner’s note. Or worse, the Planner’s note overwrote the Crew’s work. We ordered a part we did not need. We sent a crew back to a fixed sensor. We wasted $5,000 because the software could not handle two truths at once.
The Fragile Link: The Split Brain
When you work offline, you are creating a divergent timeline. The device has one version of the world. The server has another. This is unavoidable. It is the nature of disconnected work.
The failure happens when they reconnect. Most cheap software uses a “Smasher” approach. It smashes the new data over the old data. It does not look inside.
If your tool does this, it is fragile. It assumes only one person works at a time. In a real operation, ten people work on the same system.
The Sturdy Fix: Granular Merging and Audit Trails
We need a system that acts like a striped vest—high visibility. We moved to a “Field-Level Sync” strategy.
1. Merge at the Field Level. If Crew A updates the Status, and the Planner updates the Notes, both changes should survive. The system should stitch them together.
- Status: Operational (From Crew A)
- Notes: Order parts (From Planner)
2. The Conflict Flag. If both touch the Status, the system must stop. It cannot guess. It must flag the record: “CONFLICT DETECTED.” It puts the record in a quarantine queue.
3. The Human Tie-Breaker. Every morning, the Data Controller checks the quarantine. They see:
- Version A (Field): “Fixed.”
- Version B (Office): “Broken.” They call the crew. “Did you fix it?” “Yes.” They accept Version A.
[TO EDITOR: Diagram showing the flow: Conflict -> Quarantine Queue -> Human Decision -> Master Database]
History is Safety
We also enabled “Immutable History.” We never delete the old value. We stack the new value on top. We can always scroll back and see what the Planner wrote, even if the Crew overwrote it.
Data is not just current state. Data is a story of what happened. If you lose the story, you lose the audit trail. Do not let the machine decide which truth is real. Build a mechanism to handle the collision without a crash.
FAQs
Why not just lock the record so only one person can edit?
Because you are offline. The server cannot tell Crew B that Crew A has the lock. Locking requires a connection. We don't have one.
Can't the server just merge them?
Sometimes. But if two people change the status of the same item, the server doesn't know who is right. The server needs to ask a human.
What is 'Last Write Wins'?
It is a lazy strategy where the last data to arrive overwrites everything else. Avoid it. It destroys history.