For critical tools with no export or backup: either establish automated exports + alternatives, or consciously accept the single-point-of-failure risk in writing

Why This Is a Rule

A critical tool with no export function and no backup strategy is a single point of failure in your cognitive infrastructure. If the tool's company shuts down, raises prices 10x, suffers a data breach, or simply changes in a way you can't tolerate, your data is trapped. This isn't a hypothetical risk — it's a routine occurrence in the tool ecosystem. Services shut down, get acquired, pivot, and break backward compatibility constantly.

The binary choice — mitigate or accept — prevents the third (worst) option: unconscious risk, where you use the tool without acknowledging the vulnerability. Unconscious risk means you discover the single point of failure at the moment of failure, with zero preparation and zero alternatives. The binary forces conscious engagement with the risk, regardless of which path you choose.

Mitigate means establishing automated exports (3-2-1 backup rule: 3 copies of critical data, on 2 different media types, with 1 stored offsite — redundancy protects against correlated failures's backup rule) and identifying viable alternatives (a tool you could switch to if needed). Accept means writing down: "I am using [tool] for [critical function] with the knowledge that I cannot export my data and have no backup. If this tool fails, I will lose [specific data]. I accept this risk because [reason]." The written acceptance is the key — it prevents denial and ensures the risk was a deliberate choice, not an oversight.

When This Fires

• During tool stack audits when identifying tools with no export capability
• When Offline capability audit: disconnect, test each critical tool for 10 minutes, grade fully/partially/dependent — find local-first alternatives for dependent critical tools's offline audit or Verify data portability before committing: actually export, actually import in another tool, actually check for structure and metadata loss's export verification reveals a critical tool with no portability
• When a tool you depend on shows signs of instability (layoffs, pivots, acquisition rumors)
• Complements Choose open portable formats (Markdown, CSV, JSON) over proprietary — migration cost compounds daily with every new piece of locked-in data (open format preference) and Verify data portability before committing: actually export, actually import in another tool, actually check for structure and metadata loss (export verification) with the risk-management framework for non-portable tools

Common Failure Mode

Unconscious lock-in: using a critical tool with proprietary data storage for years without acknowledging the risk. When the tool fails or becomes unacceptable, you discover you have no exit path. The data — years of notes, projects, or records — is effectively lost. The risk was real the entire time; you just never confronted it.

The Protocol

(1) For each critical tool, answer: "Can I export all my data in an open format?" and "Do I have a backup of this data?" (2) If both answers are "yes" → no action needed. The risk is mitigated. (3) If either answer is "no" → choose one path: Mitigate: establish automated exports (even if imperfect — a partial export is better than none), identify an alternative tool you could switch to, and create a migration plan outline. Accept: write a risk acceptance statement: "I accept the risk of using [tool] without export/backup because [reason]. The data at risk is [description]. If the tool fails, I will [contingency plan or 'accept the loss']." (4) The acceptance statement must be written, dated, and reviewed annually. Verbal acceptance doesn't prevent denial. (5) Revisit the mitigation/acceptance decision annually: has the tool added export capability? Has your data grown to the point where the accepted risk is now unacceptable? Has an alternative become available?