Spec the conflict before the field app ships.

Two true edits can still disagree

Someone captures a fact close to the work: a check completed, a note about the day, a status on a piece of equipment. The network drops. Another person, or the same person on another device, edits the same record with a different fact. Both saves are honest. When the devices reconnect, one of them will win, or the fields will braid, or the record will freeze. If you did not choose, the software will choose something and call it sync.

This note is the TWIMCO Offline Conflict Policy Card. One card, one record type. You name the win rule, the fields that may merge, the fields that must not, who is told, and what the holder of the device can still do while the conflict is frozen. You do not get a universal rule from this page. A counter of completed steps and a free-text note about a person’s day are not the same object.

There is no live tool for the card. If you are still deciding whether the capture product should exist, start from the live custom product build brief. The brief will not invent your win rule.

WorkStep project work helped companies understand frontline workers and the conditions of the working day. That is the shape of capture this card is for: information written close to the work, often away from a stable desk. There is no public WorkStep case-study page, and the project record does not document an offline architecture. Do not cite WorkStep as proof of a sync design. Cite it as the reason the policy has to exist before field capture ships. The public case to read is Spin:Market. TWIMCO built the application and the player software; commands go to devices, and playback status and device events come back. The product does not assume the room matched the intent just because a command was sent. That is not an offline-merge case study. It is the standard that both ends of a connection are facts, and disagreement has to be representable.

Write the card before the first build that queues local writes. A queue without a policy is a future overwrite with a progress spinner.

Put the rule on one card

Fill these lines for a single record type. If you have three record types, you have three cards. Sharing one rule “for now” is how a note field and a money field inherit the same bravery.

Record. What it is, who creates it, and which devices may hold a writable copy. If a back-office user and a field user can both edit, say so. Hidden writers are how “the server won” surprises the person who was holding the device.

Win rule. Pick one primary rule and write the sentence:

• Server wins. Local edits against a newer server version are rejected and shown, not discarded silently.
• Client wins. Dangerous, and only for fields you list. A client win on everything is a last-device-to-reconnect wins, which is a race.
• Field merge. Some fields combine; others do not. The card lists both.
• Freeze. Neither version becomes current until a named role resolves the clash. Both versions stay readable.

You may mix freeze for some fields and merge for others. You may not mix them by accident because the library’s default is “last write.”

Merge fields. Only fields where both edits can be kept without lying: appended notes, distinct checklist lines, independent attachments. Say how order is determined. Do not use the device clock as the order. Clocks drift. Use server receipt order, or an explicit sequence the server issued before the device went offline, and write which.

Frozen fields. Identity, status that gates money or access, anything where two values cannot both be true. On conflict these keep the last accepted server value, or they freeze the record, as you specified. The losing local value stays visible as a rejected proposal so the person can re-enter it on purpose. Vanishing edits teach people to keep a paper backup and bypass your app.

Notify. Who hears that a conflict opened: the editor, the other editor, a record owner. A badge nobody’s role is responsible for is not a notify line. Name the role.

While frozen. What the device may still do. Read, add a comment, retry connectivity. Not silently keep editing the frozen fields in a way that creates a third version. If work must continue, the card says which substitute record they open.

Already pushed. If one device uploaded and triggered a side effect—a message, a job, a command to hardware—the conflict policy does not roll that back by magic. Point at the compensating action, or say there is none and a human must look.

The card is incomplete if the win rule, the frozen-field list, or the notify role is blank. Incomplete means you do not ship offline writes for that record. Online-only is an acceptable release. Pretend-offline is not.

Reconnect is a decision, not a spinner

Walk two devices through a single record so the team can see the states. Use test identities. This is a rehearsal shape, not a client log.

Both devices read the same version. The server has given them a version token. Each makes a different edit while offline. Each holds the edit locally and shows it as not yet confirmed. That local honesty matters. A checkmark that means “saved on this phone” is a different mark from “accepted by the record.”

One device reconnects and is accepted. The record’s version moves. The other device reconnects and presents its edit against the old token. The policy runs. If the fields are mergeable, both texts remain and the owner is told. If the fields are frozen, the record shows the clash: accepted value, rejected local value, time of receipt at the server, and the role who must resolve it. The rejected value is not applied and not deleted.

Resolution is an explicit act by that role, with the same kind of trail you would want on any overwrite: who chose, which version, and whether the rejected text was copied forward. Automatic resolution is allowed only for the merge fields you listed, and only by the rule you wrote. “The library merged it” is not a rule.

Clock skew belongs in the rehearsal. Set one device’s clock ahead and show that it does not win because of that. If the demo cannot show this, the card’s ban on device-clock authority is fiction.

Side effects belong in the rehearsal too. If the first accepted edit already notified someone, the second device’s rejection screen says so. People can tolerate a rejected edit. They do not tolerate a notice that went out from a value the record no longer shows, unless the card told them that could happen.

Spin:Market is the public picture of a command that must not be mistaken for the resulting state: the player reports status back. A field app owes the same separation. “Saved locally” is the command. “Accepted, merged, or frozen” is the state that comes back. WorkStep-style frontline capture makes the stakes plain—notes about a working day are easy to overwrite and hard to recreate—but the project is context, not evidence of a conflict engine. Your rehearsal notes are the evidence.

Sync stories that hide a lost edit

Composites, not measurements from a field deployment.

Last reconnect wins. Two supervisors close the same checklist differently. The later phone overwrites the earlier upload. No one is told. The day’s record is whichever door had signal last.

Merge that is actually concatenation garbage. A status enum is “merged” into a string nobody’s screen can read, or two contradictory statuses both display as true. The card said merge because the team liked the word.

Silent drop. The losing edit disappears. The worker is sure they recorded a hazard or a preference. The system is sure they did not. Trust in capture falls, and the next notes go into a personal notebook.

Clock champion. A device with a wrong clock sorts first and its note lands above a later real event. The timeline of the day is now a timeline of battery settings.

Freeze with no owner. The record locks. The badge sits. The role line was blank, so the freeze is a stuck state with a spinner beside it. People force-quit and create a duplicate record, which is a second conflict you also did not spec.

When you see these, stop adding retries. Fill the card. The unreproducible asset is the filled TWIMCO Offline Conflict Policy Card for one record type, plus the rehearsal where a skewed clock failed to win and a rejected edit stayed visible. A sync vendor’s brochure does not contain your frozen-field list. The list is the part that has to be yours.

Keep the card next to the record’s source-of-truth note if you have one. Authority and conflict are different questions. The source of truth says which system wins between server and server. This card says what happens when two writers were both honest and both offline. Mixing the documents is how “the server is the source of truth” becomes an excuse to delete a field note without telling its author.

Web applications is the right scoping conversation when the product cannot show local-versus-accepted as different states. If the capture is part of a larger operational handoff, business process automation belongs in the same discussion. Either way, do not ship the queue first.

Put this into practice

1. Pick the one record type a field device will edit without a guarantee of network.
2. Choose a win rule. List merge fields and frozen fields. Name who is notified and what the device may do while frozen.
3. Write that the device clock is not authority, and how order is actually decided.
4. Rehearse two offline edits, a rejection that stays visible, and a skewed clock. Do not ship the offline queue if the losing edit vanishes.
5. File the card with the build. If you need a partner to make local and accepted states unmistakable, bring the card to web applications. Read Spin:Market for a product that treats device-reported state as a fact of its own. Use WorkStep as frontline context only—there is no public case-study URL to cite as sync proof.

The reconnect spinner is not a policy. The card is.