Abstract
A writing system can show a calm status cue, make a current manuscript easy to open, and still leave the path back to a needed earlier state unclear. This paper calls that condition recovery responsibility drift: the quiet transfer of preservation and restoration work from a system to a person when the trigger, destination, version relation, feedback, failure state, and return route are not sufficiently visible or actionable. The purpose is not to accuse a system of failure or ask every writer to become a storage administrator. It is to separate reassurance from evidence. Using a constructed editorial record, six inspected sources, and an original thirteen-field Backup Recovery Trace, the paper teaches readers to follow one bounded record from change through protection to a possible return. It distinguishes a protection signal from a recoverable state; a stored copy from an identifiable version; a visible status message from a failure signal; and an automatic routine from a rehearsed return path. The Trace produces neither a score nor a prescription. It records the smallest question that remains before a stronger claim about recovery can responsibly be made.
1. A calm icon and an unanswered question
At 6:07 on a Thursday evening, Mara closes an editorial draft with a small piece of good news still on the screen. The paragraph she has just revised bears a status cue: the manuscript is protected. Her laptop is connected. The cue has stopped moving. She does not photograph it, write it down, or ask where the version went. There is no reason to. The point of the cue is to let her stop thinking about it.
Three weeks later, a contributor asks to see the version before a set of structural cuts. Mara opens the current manuscript, then the visible version list. The version she needs is not where she expects it. Nothing dramatic has happened. Her account opens. The current file is there. The newer edits are there. The problem is narrower and more unsettling: she cannot yet tell whether the earlier state is absent, somewhere else, excluded from a retained history, available only through another device or role, or recoverable by a route she has never had to use.
This is not a story about a negligent editor or a defective product. It is a story about a sentence that often does too much work: “It is backed up.” The sentence may be true, useful, and still incomplete. What was protected? By what event? To which destination? In what version relation? What would show Mara that the needed state can return? And, if she cannot answer, whose responsibility is it to make the answer findable?
A protection cue has a humane purpose. It reduces repetitive care and can make editorial work less brittle. The alternative is not necessarily more agency; it can be an impossible demand that every writer become a storage administrator. Yet routine labor can be reduced while the path back remains hard to describe. The central question is therefore neither “Why did Mara not make a copy?” nor “Which system should she use?” It is this: when one particular working state must return, what evidence shows that the route is there, and where does responsibility become unclear?
This paper calls the obscured handoff recovery responsibility drift. The phrase does not name a defect, a person, or a vendor. It names a relation. A system may perform some protection work well while asking a person to infer the status of another part: which version was retained, how long it remains available, whether comments travel with the text, what access relation enables return, or what a failed protection event would look like. Drift begins when those questions become relevant only after the ordinary reassurance has ended.
The paper is a diagnostic teaching instrument. It does not decide whether a service should be trusted, renewed, purchased, cancelled, migrated from, or treated as an archive. It does not prescribe a backup schedule, a number of copies, a format, a security configuration, or a local-first architecture. Its concern is smaller and more immediate: one working record, one claimed protection path, and the evidence required to understand a possible return.
2. Protected is not yet recoverable
The ordinary experience of protection and the later experience of recovery are not the same event. A current cue may refer to a completed transfer, a synchronized state, a saved change, a queued process, or a status known only to the service. A recovery question is different. It asks whether a particular needed state can be found, identified, reached, opened, and used in the relevant relation.
A 2025 survey by Wunder and colleagues provides a careful reason to maintain that distinction. The study surveyed 1,423 people in Germany, the United Kingdom, and the United States about data loss and recovery on devices for personal use. Its abstract reports that 656 participants had experienced at least one data-loss incident; among those respondents, 42% recovered using backups, and 24% had outdated or incomplete backups.[1] The study does not predict Mara’s outcome, establish a failure rate for creative work, or identify a defect in any named tool. It does show why “a backup exists” and “the needed state can return in the needed condition” should remain separate propositions.
Kljun, Mariani, and Dix provide an earlier view of the same distance. In their mixed quantitative and qualitative study of 319 participants, they report manual, selective, noncontinuous, and sometimes incidental backup practices, along with reported limits on restoring important files and folders after computer failure.[2] The significance is not that selectivity is irresponsible. A writer may have good reasons to distinguish an active manuscript from a cache, a contributor’s comment thread from a temporary export, or a final proof from an abandoned branch of revision. The difficulty begins when the compact phrase backed up conceals these distinctions rather than making them discussable.
For an editor, a recoverable record has at least four relational conditions. First, the object must be bounded: “the comments on the March structural edit” is a more useful object than “the project.” Second, the needed state must be identifiable: before which cuts, after whose revision, in which relation to source notes or comments? Third, a route must exist from the present moment to that state. Fourth, someone must be able to recognize whether the returned object is the one sought. A returned file with the wrong version relation may be a successful transfer and an unsuccessful recovery.
| Term | Useful meaning in this paper | What it does not establish alone |
|---|---|---|
| Protection event | A save, sync, schedule, export, version event, or other event said to create a protected state. | That every relevant part of the work was selected or retained. |
| Stored state | A copy or representation exists somewhere. | That a person can locate it, identify it, or restore it in the needed condition. |
| Recoverable state | A defined record can be reached and returned through an understood route. | That the record will remain interpretable, complete, secure, or archivally adequate in every future setting. |
| Recovery evidence | A bounded fact, test, or explanation showing what one part of the return path does. | A guarantee that all other parts of the path will work. |
The table is intentionally modest. It does not create a hierarchy in which all writing must attain a final condition called recovery. Its purpose is linguistic. When an editor asks whether something is protected, stored, recoverable, or evidenced, the question becomes more precise and the next inquiry can become smaller.
3. Follow the return path, not the reassurance
Mara’s needed earlier version cannot be understood by looking only at a status cue. She needs to trace a path. A useful path begins with the moment a record changed and continues through the moment a person could return to a relevant earlier state. Each stage is a possible handoff, and each handoff may be visible, invisible, automated, manual, shared, or unknown.
| Return-path moment | Question for the record | What can become unclear |
|---|---|---|
| Change | Which revision, comment, media object, or state matters? | The object is described too broadly to be checked. |
| Protection trigger | What event supposedly created protection? | A cue is read as proof without knowing what action produced it. |
| Destination | Where is the relevant protected state expected to be? | A generic service label substitutes for a known location or relation. |
| Version relation | How does the needed state relate to the current one? | Any returned text is mistaken for the required earlier state. |
| Status feedback | What does the visible indication actually say? | A general “up to date” message is treated as proof of retained scope and return. |
| Failure signal | How would a missing selection, expired version, failed transfer, or inaccessible return become visible? | The first signal arrives only at the moment of need. |
| Restore entry | Where would a person, collaborator, or support role start the return? | A copy is assumed to be usable because it exists. |
| Rehearsal | What limited part of this route has actually been checked? | The entire route is inferred from a familiar routine. |
This is a return path, not a storage architecture. The path can cross a local device, a shared workspace, a removable drive, a service relationship, a collaborator’s permission, or a support conversation. WEXLEY-WP-021 considers whether local-first architecture can support stewardship of a live manuscript. WEXLEY-WP-024 asks what current account access warrants as a custody claim. WEXLEY-WP-027 does neither. It follows one potential route back from a present question to a specific earlier editorial state.
Historical systems research helps make this distinction concrete without providing a current product verdict. In 2010, Hu, Yang, and Matthews experimentally tested four consumer cloud-storage offerings then available. They reported variation in backup and restore performance, variation in default data selection, and an observed case in which expected data could not be restored.[3] Their work is historical, and it must not be used to characterize those or other services now. Its durable teaching value is narrower: an automatic arrangement contains separable conditions of selection, transfer, retained scope, restore behavior, and return. A completed transfer is not a complete answer to a return question.
Suppose Mara’s system has successfully protected the text of the manuscript but not the contributor comments that make the earlier state editorially meaningful. Suppose it retained an earlier version but the version is visible only to a different role. Suppose a returned text opens but does not make clear whether it predates the cuts in question. None of these possibilities establishes a loss. Each identifies a different unknown. The point of tracing the path is not to multiply anxiety; it is to stop vague anxiety from forcing an oversized answer.
4. Recovery responsibility drift
Recovery responsibility drift occurs when a system supplies enough reassurance for ordinary work but leaves the person who later needs a return to reconstruct a hidden chain of actions, relations, and limits. The responsibility may drift from an interface to an editor, from a routine process to a collaborator, from a visible status cue to undocumented memory, or from a technical system to a support relationship. The person is not necessarily incapable. They may simply be the last person in the chain with information that was never made available.
The construct is a teaching label, not an empirical measure. It is built from a recurring tension in the evidence: users may create backups but later encounter an incomplete or outdated return; users may perform selective protection without knowing the implications of the selection; and a system may perform a successful operation without making its scope or return route legible.[1] [2] [3] The diagnostic question is therefore not “Who failed?” It is “At which handoff did evidence stop?”
Redmiles and Hargittai’s longitudinal study helps keep this question from becoming a competence judgment. Using a panel survey of 384 diverse young adults, they modeled reported mobile and computer backup behavior and found an association between Internet skills and reported backup frequency; increases in Internet skills were associated with more frequent computer backups in their panel.[4] This does not mean that skills cause recovery success or that people who protect work less frequently are careless. It does suggest that support conditions matter. An environment that relies on a user to infer technical state, maintain a private mental model of version retention, or discover a hidden restore entry is assigning work unequally.
A productive diagnostic changes the sentence “the user should know” into a series of inspectable questions. What feedback existed? Was it attached to the particular record, or only to a general service state? Could a person see the relevant version relation before a crisis? Was the restoration entry visible to the people who might need it? Was a handoff to a collaborator or support role named? What would count as a failure signal before the one needed version mattered?
The last question is especially important. A system need not disclose every internal operation to be caring. It does need, in proportion to the task, a way for people to discover the meaningful limits of its assurance. A visible “protected” signal can be valuable. A visible route to the relevant version, a bounded explanation of retained scope, or a comprehensible statement of what remains unknown can make that value more trustworthy without demanding manual duplication of every action.
5. The Backup Recovery Trace
The Backup Recovery Trace is a thirteen-field inquiry record for one bounded creative object. It should be used when an author, editor, program lead, archivist, or tool steward needs to turn a general assurance into a specific account of a possible return. It is not a checklist with correct answers. A field may remain unknown. The unknown is often the finding.
| Field | What to record | Teaching question | Mistake avoided |
|---|---|---|---|
| 1. Working record | The specific draft, notes, comments, media, or collection at issue. | What exactly must come back? | Treating a whole working life as one object. |
| 2. Protection trigger | The save, sync, schedule, version event, export, or other action said to create protection. | What event starts protection? | Treating a cue as an explanation. |
| 3. Destination | The known location or service relation for the relevant state, if known. | Where is that state expected to be? | Replacing an unknown destination with a reassuring label. |
| 4. Version relation | The relation of the needed state to current, prior, shared, or exported versions. | Which state is needed, and how would it be recognized? | Treating any returned file as the one sought. |
| 5. Status feedback | What the system visibly says, when, and about which portion of the path. | What does the cue actually evidence? | Reading status as proof of recoverability. |
| 6. Failure signal | What would become visible if protection, selection, destination, or return failed. | How would a problem announce itself? | Learning of a failure only in an emergency. |
| 7. Restore entry point | The known place, role, command, conversation, or documentation through which a return begins. | Where does the first recovery action start? | Confusing a copy’s existence with access to a return path. |
| 8. Recovery rehearsal | A bounded check already made, or the uncertainty that remains. | What small return question has actually been tested? | Calling a routine reliable because it is familiar. |
| 9. Account/device dependency | The account, device, network, permission, or role relation currently required for return. | Which present condition does recovery depend on? | Mistaking a recovered object for an independent pathway. |
| 10. Handoff responsibility | The point where a system, service, collaborator, or user must act or supply evidence. | Who must know or do what next? | Letting responsibility silently fall on the least informed person. |
| 11. Countervailing automation gain | The continuity, access, safety, or maintenance benefit automation already supplies. | What useful condition would a change endanger? | Turning inquiry into anti-automation rhetoric. |
| 12. Evidence-needed question | The smallest fact, explanation, or limited check required next. | What would reduce uncertainty proportionately? | Responding to every unknown with a maximal technical project. |
| 13. Non-conclusion | What cannot responsibly be claimed yet. | Which reassurance or recommendation remains unearned? | Converting a trace into a verdict about a person or product. |
The Trace does not ask whether a system is “good” or “bad.” It asks a sequence of linked questions about an object and a possible return. For Mara, the working record might be “the contributor-commented manuscript before the March structural cuts.” The protection trigger might be the version event that followed her Thursday revision. The version relation would describe why the pre-cut state, not merely an earlier file, is needed. The failure signal might be unknown. That uncertainty is not an indictment. It is a documented handoff that needs a proportionate next question.
A trace can reveal that nothing needs to change. Mara may discover a clearly labeled version, a usable comment relation, and a visible restore entry. It can also reveal that a requested change would sacrifice an important automation benefit. The instrument therefore includes the countervailing automation gain as a required field. Inquiry should not pretend that manual procedures are automatically safer, more accessible, or more equitable.
6. One proportionate rehearsal
The word rehearsal can sound larger than this paper intends. It does not mean staging an outage, simulating a crisis, or demanding that a writer recover an entire project on a schedule. Here, a rehearsal is a small, bounded attempt to answer one named return question before the answer is urgently needed.
NIST’s contingency-planning guidance operates at a very different scale from an author’s manuscript. Its setting is federal information systems, and its procedures should not be imported into private creative work. Yet the distinction it makes is useful: backup/recovery operations, tests of operability, roles, and reconstitution are different kinds of work.[5] A process may run. A role may be assigned. A test may validate one condition. None of these statements silently contains the others.
The Digital Preservation Coalition’s guidance on fixity offers a related conceptual distinction. It explains that checksums can help detect that a file has changed but do not identify where the change occurred. With multiple copies and known reference values, a known-good copy can support repair of a corrupted one.[6] This is preservation-program language, not a command that Mara calculate checksums. Its contribution is to separate integrity evidence, detection, and repair. A status signal may describe one part of a system without describing the others.
For a creative record, a proportionate rehearsal might be one of the following questions:
| Named uncertainty | A proportionate rehearsal | Useful evidence | What it does not prove |
|---|---|---|---|
| “Can I identify the pre-cut state?” | Locate one older version and compare its relation to the known edit point. | A labeled version relation or a documented ambiguity. | That every historical version is retained. |
| “Do comments return with the manuscript?” | Open one selected earlier state and inspect whether its required comment relation is present. | A narrowly described observation. | That all collaboration history is complete or archivally adequate. |
| “Where would return begin?” | Ask the person or consult the documentation that identifies the first restore entry. | A named entry point and handoff role. | That the entire return route has been tested. |
| “What does this status cue mean?” | Read the description attached to the specific status and record its stated scope. | A bounded account of the cue’s meaning. | That the stated process covers every relevant condition. |
| “What happens when a version is unavailable?” | Record the known failure signal or the fact that no visible signal has been found. | A named uncertainty and next evidence question. | That unavailability will occur. |
A rehearsal produces evidence of one thing. It should be recorded as one thing. “A selected earlier draft opened with its comments on this date” is more responsible than “our work is safely recoverable.” “The team identified a restore entry point but did not test a return” is more useful than either reassurance or panic. The point is to make the boundary of knowledge legible.
7. Automation is not the enemy
The critique in this paper is not that automated protection exists. Automation can keep work available across devices, reduce repetitive maintenance, protect a person from a fragile manual habit, and make a return more realistic than no protection at all. Wunder and colleagues report that 86% of their full sample created full or partial backups of at least one device.[1] That prevalence does not prove that all returns work, but it does indicate that ordinary people use a range of protective arrangements as part of their practical lives.
The appropriate counterquestion to every proposed change is therefore: what current benefit would this change endanger? A manual export routine might introduce labor a collaborator cannot reliably perform. A local requirement might exclude a person whose only workable access is shared or mobile. A more visible failure signal might create an anxiety burden if it is poorly explained. A system can be improved by exposing a meaningful handoff without removing the protective convenience that made the system usable.
Recovery responsibility drift is not a demand to eliminate delegation. Delegation is often necessary. The issue is whether it is legible. A person can sensibly delegate background protection to a system while retaining a way to ask what the protection includes, what an available status cue means, where an earlier state can be found, and who can help if a needed return is unclear.
8. What the Trace does not decide
The Backup Recovery Trace does not decide whether an account is an archive. WEXLEY-WP-024 maps the difference between present account access and a warranted custody claim. WEXLEY-WP-027 only records an account or device dependency when it affects a particular return path.
The Trace does not decide which architecture should be adopted. WEXLEY-WP-021 examines local-first software as an authorial preservation strategy. A destination in this paper is an observed relation within a possible recovery route, not an endorsement of local, remote, or hybrid design.
The Trace does not model threats, confidentiality exposure, encryption, or permissions architecture. Those questions belong to the stage-sensitive privacy work of WEXLEY-WP-025 and the collaboration/security inquiry reserved for WEXLEY-WP-030. Nor does it decide which revision records should be retained or forgotten (WEXLEY-WP-026), which formats or metadata should travel to a literary archive (WEXLEY-WP-028), how recurring infrastructure costs should be assessed (WEXLEY-WP-029), or whether a subscription should be renewed, cancelled, or exited (WEXLEY-WP-043).
Finally, the Trace cannot certify recovery. A small rehearsal can reduce one uncertainty. It cannot guarantee every future return, establish legal rights, substitute for an archive policy, or erase the difference between a bounded creative question and an institutional continuity plan.
9. Return evidence, not reassurance
Mara’s status cue was not meaningless. It told her something useful at the time she saw it. The difficulty emerged later because the cue did not, on its own, answer the new question: where was the pre-cut version, what relation did it retain, and who could help her return to it if it was not visible?
The Recovery Trace gives Mara a way to move without overreacting. She can name the record, identify the assumed protection trigger, ask what the cue actually evidenced, distinguish the earlier version from the current file, record the unknown return entry, retain the convenience that automation already provided, and choose one small question to inspect. Her next act might be as simple as locating one earlier state, reading a visible description of version retention, or asking a collaborator which role controls a return. It need not be a migration, a purchase, a configuration project, or a declaration of failure.
The final question is therefore not whether a writer has “done backup correctly.” It is whether a particular needed state has a legible route back. When evidence stops at a handoff, the responsible response is not a verdict about the user or the system. It is a better question: what is the smallest fact, test, or explanation that would make this return path understandable enough to rely on for this work?
References
[1] J. Wunder, R. Wash, K. Renaud, D. A. Oliveira, and Z. Benenson, “Achieving Resilience: Data Loss and Recovery on Devices for Personal Use in Three Countries,” CHI ’25: Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems, 2025.
[2] M. Kljun, J. Mariani, and A. Dix, “Toward Understanding Short-Term Personal Information Preservation: A Study of Backup Strategies of End Users,” Journal of the Association for Information Science and Technology, vol. 67, no. 12, pp. 2947–2963, 2016.
[3] W. Hu, T. Yang, and J. N. Matthews, “The Good, the Bad and the Ugly of Consumer Cloud Storage,” ACM SIGOPS Operating Systems Review, vol. 44, no. 3, pp. 110–115, 2010.
[4] E. M. Redmiles and E. Hargittai, “New Phone, Who Dis? Modeling Millennials’ Backup Behavior,” ACM Transactions on the Web, vol. 13, no. 1, art. 4, pp. 4:1–4:14, 2019.
[5] M. Swanson, P. Bowen, A. Phillips, D. Gallup, and D. Lynes, “Contingency Planning Guide for Federal Information Systems,” NIST Special Publication 800-34 Revision 1, May 2010.
[6] Digital Preservation Coalition, “Fixity and Checksums,” Digital Preservation Handbook, accessed 2026-08-20.