When two tools hold the same data, designate one canonical source of truth — demote the other to capture-point or read-replica to prevent sync drift
When two tools in your stack both maintain authoritative copies of the same data type, designate one as canonical (single source of truth) and demote the other to either capture-point (temporary holding before transfer) or read-replica (displays data but cannot edit) status to prevent sync drift.
Why This Is a Rule
When two tools both maintain authoritative copies of the same data — tasks in both your email and your task manager, contacts in both your phone and your CRM, notes in both your meeting app and your knowledge base — sync drift is inevitable. The copies diverge silently: you update the task in one tool but not the other, and within weeks you have two conflicting versions of truth. Which one is current? Neither, and both, and you don't know which edits exist where.
The solution is the database principle of single source of truth: exactly one system is authoritative for each data type. All other systems that display or interact with that data are either capture points (temporary holding areas where data enters the system before being moved to the canonical location) or read replicas (views that display canonical data but cannot edit it).
This architecture eliminates sync drift because there's nothing to sync: the canonical system holds the truth, capture points feed into it, and read replicas display from it. Two authoritative copies need bidirectional sync (fragile, complex, error-prone). One canonical source with capture and display endpoints needs unidirectional flow (simple, reliable, maintainable).
When This Fires
- When the same information exists in multiple tools and you're not sure which is current
- When "sync issues" cause missed tasks, conflicting data, or lost updates
- When designing a multi-tool workflow and deciding where data lives
- Complements Automate the single highest-frequency manual data transfer first, verify for one week, then iterate — sequential automation prevents fragile webs (automate highest-frequency transfer) with the architectural decision that makes automation meaningful
Common Failure Mode
Dual-authority systems: tasks in both Todoist and Notion, both treated as authoritative. You add a task to Todoist on your phone, mark a different task complete in Notion on your laptop, and neither system reflects the other's changes. Two weeks later, you miss a deadline because the task existed in one system but not the one you checked.
The Protocol
(1) List every data type in your tool stack: tasks, notes, contacts, calendar events, project status, reference materials. (2) For each data type, identify all tools that contain it. (3) For each data type with 2+ tools: designate one as canonical. This is the source of truth for that data type. All edits happen here. (4) Demote other tools to capture point (data enters here temporarily, then gets transferred to canonical — e.g., quick-capture app → main task manager) or read replica (displays data from canonical but is not directly editable — e.g., calendar widget showing tasks from your task manager). (5) Document the designations: "Tasks: canonical = Todoist. Notion task view = read replica. Apple Reminders = capture point (transfer within 24 hours)."