frontend-patterns/research/candidates/ConflictCopy.md

---
title: Conflict Copy
status: draft
maturity: hypothesis
families: [synchronization]
scales: [L2, L6]
admission: research-candidate-only
reviewed: '2026-09-25'
---

# Conflict Copy

A research candidate, not a canonical pattern or a completed PatternSchema record.
No FEP identity or admitted graph edges. Editorial synthesis by codex; live artifacts
remain unchanged. Merges Joplin `joplin-conflicts-01/P01` and Obsidian
`obsidian-conflicts-01/P01` (Conflict File Preservation).

## Context and problem

A system detects divergent edits to one document. It can select a working version,
but cannot infer which combination expresses the user's intended result. How can
it retain the alternate edits for a later decision without treating selection of
the working version as semantic resolution?

## Competing forces

- `recoverability` favors retaining divergence; `cognitive-load` and storage costs
  favor avoiding an expanding collection of unresolved copies.
- `freshness` favors applying received changes; `reconciliation-complexity` favors
  postponing a merge whose meaning is uncertain.
- `discoverability` and `accessibility` require a perceivable conflict state; silent
  duplication can preserve bytes while still failing the user.

## Proposed solution and dynamics

Where access and retention policy permits, on a detected conflict preserve the
alternate content under a distinct identity
and associate it with the working item. Select a working version according to an
explicit policy. Keep resolution pending until a person or separately justified
merge mechanism decides what to retain. In the two documented uses, the preserved
copy is local content and the working item holds remote content; that selection is
not a general claim of server authority.

Durably preserving before destructive replacement, labeling provenance, notifying
the user accessibly, and making resolution restartable are proposed design
requirements. They are not verified implementation guarantees from these sources.

## Resulting context and consequences

The working item is usable, but divergent intent remains unresolved. A copy may
support recovery and comparison; it does not prove convergence, preserve every
historic edit, or protect against failure of the device holding both versions.
Manual reconciliation creates effort, clutter and opportunities for mistakes.

## Located uses and limits

[Evidence review](../reviews/LocalFirstEvidenceExpansion.md):

- SRC-0005 / E07: Joplin's documented detected-note-conflict handling.
- SRC-0006 / E08: Obsidian Sync's optional conflict-file mode, not its default mode.

These are two named documented uses from separate application publishers, not two
fault-tested deployments. Recurrence has limited documentary support; retain
hypothesis maturity. The applications' shared code lineage was not investigated.
Obsidian's alternative merge mode and creation-time exception (E09/E10) prevent an
unconditional claim that this mechanism is always used or never loses data.

## Failure cases and alternatives

- A crash during preservation/replacement needs an atomicity or recovery argument.
- Missed conflict detection bypasses this mechanism entirely.
- An unnoticed copy can leave the user believing work disappeared.
- Concurrent resolution on two devices can itself conflict.
- Replicated deletion or local corruption can affect both versions; use separate
  recovery protection (E11), not a claim that synchronization is a backup.
- Alternatives: halt for immediate review; domain-aware automatic merge; explicit
  rejection of stale writes. Compare semantic correctness and user effort.

## Relations to investigate

Potentially complements Local Authority and may create context for Explicit
Reconciliation. These names refer to research candidates, not admitted endpoints.
Conflict detection is a contextual prerequisite, not a fabricated pattern edge.
The mechanism may preserve rejected edits in VC-01 but cannot validate a reservation,
approval or other globally constrained transaction.

## Next test

For VC-02, edit one note on two disconnected devices, persist both, restart, then
reconnect. Trace local-save acknowledgement, working-version selection, conflict
notification, resolution and separate backup recovery. Compare with a plain
architecture narrative and with immediate manual merge. A first [synthetic walkthrough](../walkthroughs/VC02-OfflineFieldNotes.md) now
traces this sequence. No runtime execution or proven generativity benefit is claimed.

## Policy boundary — 2026-09-26

Define who may inspect, retain, export and delete each version, including after
access changes. A conflict does not grant permission to preserve restricted data.
If policy requires deletion, explain the resulting recovery limit without exposing
the removed content. Retention and export are decisions, not unconditional safety
requirements. See [shared guidance revision](../reviews/SharedGuidanceRevision.md).