Abstract
A writer is preparing to send a manuscript to an editor. The current draft opens on a laptop. A tablet holds a recently synchronized copy. A remote service has another copy. A backup system retains some earlier states. A PDF will be attached to an email. Asked a simple question—where is the manuscript?—the writer has several answers, and none is complete.
This paper offers the manuscript stewardship stack as a teaching construct for making that situation legible. The stack separates seven conditions: access, custody, replication, recovery, intelligibility, provenance, and selective disclosure. Its purpose is not to declare a winning application architecture. It is to show that a local primary copy can increase operational agency and offline resilience without automatically supplying a backup, recovery test, long-term interpretation, collaboration governance, or privacy boundary. Conversely, a managed service can offer replication, integrity checks, specialist operations, and recovery capacity without settling who can export the work, what happens at exit, or what the provider may do with the material.[1] [4]
The paper uses a constructed but technically bounded manuscript hand-off scenario. Its instrument, the Manuscript Stewardship Matrix, asks a writer, editor, small publisher, or product steward to record what a system enables, who bears the responsibility, what evidence should be checked, and what risk remains. The intended result is not a preservation program in miniature. It is a better question set for the active life of a draft.
1. The manuscript that has more than one location
A manuscript can be immediately present and still be hard to locate. A writer may open it on a laptop with no connection. That fact matters. The same document may also appear on a phone, a tablet, a removable drive, a remote service, an editor’s inbox, and a backup system. But those are not interchangeable locations. One may be the current working copy; another a delayed replica; another a recoverable previous state; another a flattened review copy; another a record that cannot be opened without a continuing account or a particular application.
The difficulty becomes visible at hand-off. Suppose a novelist has a 75,000-word draft. The laptop contains the version currently being revised. When a connection is available, a tablet receives a synchronized copy. A remote service holds a secondary copy. A separately scheduled backup retains older recoverable states. The writer sends a review copy to an editor, then continues working. Three weeks later, a device fails, the editor asks which file was reviewed, and the writer wants to share neither private notes nor an abandoned opening chapter.
Nothing in this scenario requires a dramatic technology failure. It describes ordinary conditions of contemporary writing: several devices, several copies, several purposes, and more than one relationship to a text. The scenario is deliberately constructed; it does not describe a named application or make a product-performance claim. Its parts are grounded in established distinctions among local storage, synchronization, backup, recovery, continuity, and preservation.[1] [5] [6] [7]
A manuscript does not occupy one place. It occupies a field of states, copies, permissions, and explanations.
That observation is not an invitation to panic or to build an archive before finishing a chapter. It is a prompt to distinguish the questions that the word saved tends to conceal. Can the writer open the work now? Can the writer take it elsewhere? Is there a copy capable of restoring a deleted or compromised state? Can a future editor understand which version was sent, and why? Can the writer share what is needed without exposing what is not?
The relevant question is therefore not simply whether a manuscript is local or in the cloud. It is whether its stewardship responsibilities are visible and proportionately carried.
2. Five terms that should not be collapsed
Local-first software has made an important intervention in this conversation. Ink & Switch describes local-first applications as treating the copy of data on a person’s own device as primary, while servers hold secondary copies that help with cross-device access. The authors contrast this arrangement with server-centric applications in which the service’s copy is treated as authoritative.[1] Their account gives a useful name to a real operational difference: a writer who can open and modify an ordinary local copy is not waiting for a remote service to authorize every act of reading and writing.
But a useful architecture is not a complete stewardship arrangement. Ink & Switch itself states that user control brings responsibility for backups, protection against ransomware, organization, and file-archive management.[1] The same paper values collaboration, longevity, privacy, and offline use, but presents these as ideals and design challenges rather than facts guaranteed by the word local-first. That limitation is a strength for this paper. It creates room for a more disciplined vocabulary.
| Term | Working meaning in this paper | What it enables | What it does not establish |
|---|---|---|---|
| Local access | A usable copy can be opened and edited on a device without a required service round-trip. | Work during ordinary network interruption; direct use of a device-held copy. | Independent backup, security, legal ownership, or long-term readability. |
| Synchronization | Copies are brought into alignment across devices or services. | Cross-device continuity and, in some designs, collaboration. | A separately recoverable earlier state or an explanation of version significance. |
| Backup | A separately held copy intended to facilitate recovery after loss or corruption. | Restoration after deletion, failure, or compromise. | A tested recovery procedure, an archive, or a guarantee that every current copy is safe. |
| Recovery | Restoring a usable state after loss, deletion, corruption, or disruption. | Return to a known usable state. | Preservation of every meaningful relation, comment, or process trace. |
| Preservation | Managed activities intended to support continued access and trustworthy use over time. | A framework for long-term continuity and interpretation. | A single storage location, format, or automated synchronization service. |
The federal cybersecurity sources are especially clear about the narrower backup distinction. CISA defines a backup as a secure copy of critical data stored separately from primary systems so it can be restored after a cyber incident, accidental deletion, system failure, or disaster. It recommends identifying what matters, keeping multiple copies across more than one kind of medium with at least one copy off-site, protecting backups, and testing restoration.[5] NIST likewise describes backup files as copies made to facilitate recovery and frames sound backup practice as conducted, maintained, and tested.[6]
Those definitions do not tell a writer to adopt an institutional disaster-recovery program. They establish a modest but important principle: a copy becomes a backup by its recovery role and separation from the primary system, not merely by its existence. A synchronized copy may be valuable, but if a deletion or corruption is faithfully synchronized, it may reproduce the problem. Whether that will happen depends on the design and retention arrangement; the existence of synchronization alone cannot answer it.
“Preservation” introduces still more questions. The Digital Preservation Coalition defines digital preservation as a series of managed activities intended to ensure continued access for as long as required. In its creator-oriented guidance, information remains usable when people can find it, open it, work with it, understand it, and trust what it is.[7] A manuscript that can be opened today but cannot be understood as a particular submission, cannot be read by any available tool, or cannot be distinguished from a private abandoned draft may fail some of these tests even if its bytes still exist.
The final term needs special care. This paper uses operational custody to mean the practical ability to access, copy, inspect, export, and move a working manuscript. It does not mean legal copyright, contractual ownership, or possession in a legal dispute. A writer may have copyright in a text while lacking a workable export. A publisher may have a contractual right to a submitted manuscript without holding the writer’s entire draft history. A device may hold a readable file that its user cannot safely disclose. Keeping these relations separate is not semantic fussiness; it prevents a technical claim about local storage from becoming an unsupported claim about rights.
3. The manuscript stewardship stack
The manuscript stewardship stack is a teaching instrument, not a period term or a systems standard. It names seven layers that should be considered separately before a writer, editor, or product team claims that a manuscript is “under control.” The layers are arranged as a stack because each can support the others while remaining incomplete on its own.
| Layer | Teaching question | Evidence a reader can inspect | Error the layer prevents |
|---|---|---|---|
| Access | Can the relevant person open and work with the current manuscript when needed? | Offline-opening test; device-held copy; compatible reader or editor. | Confusing remote existence with present usability. |
| Custody | Who can inspect, copy, export, or move the working material? | Export route; local files; role permissions; documented hand-off. | Treating an account as equivalent to practical possession. |
| Replication | How many current copies exist, where, and how do they align? | Device list; synchronization status; replication map. | Assuming all copies are current or independent. |
| Recovery | Which separately held state can restore a mistake or a compromised current copy? | Backup schedule; retention record; restoration test. | Calling synchronization a recovery plan. |
| Intelligibility | Can the manuscript later be opened, understood, and worked with? | Format or export record; application notes; read-back test. | Treating current readability as a permanent property. |
| Provenance | Can the relevant version, hand-off, and relation to review material be explained? | Naming convention; version note; submission record; change context. | Believing timestamps explain editorial significance. |
| Selective disclosure | Can necessary material be shared without revealing private drafts, notes, or collaborators? | Deliberate review copy; access settings; release decision. | Treating maximal trace retention or maximal sharing as always responsible. |
The first three layers describe the current working situation. Local access is valuable because a writer may work during a flight, a service disruption, or a period of limited connectivity. Operational custody matters because a file that cannot be inspected or moved without a provider’s current permission puts practical limits on authorial agency. Replication matters because a writer who works across laptop, tablet, and editor-held copies needs to know which state is current and whether the copies will converge.
The next two layers create a boundary between operational convenience and survival. Recovery asks whether a distinct and usable state can return after something goes wrong. Intelligibility asks whether the content can continue to be read and worked with rather than merely stored. The Coalition’s creator guidance connects this second question to software support, broadly readable files, clear names, visible version conventions, transition planning, and a dialogue between creators and repositories where longer-term preservation is at stake.[7]
The last two layers guard meaning and restraint. Provenance asks what makes one version the version that was reviewed, submitted, accepted, or published. Selective disclosure recognizes that a strong creative record does not require indiscriminate exposure. A working file may contain a collaborator’s comments, private research, names that should not circulate, abandoned passages, or material that would be misleading if treated as a finished statement. The purpose of stewardship is not to retain and reveal everything; it is to make a deliberate account of what should endure, for whom, and under what conditions.
4. The manuscript at hand-off
Return to the novelist’s hand-off. The writer needs to send a review copy to an editor. The editor needs to know which document is under review, not necessarily to see the writer’s entire work history. The writer needs confidence that a device failure will not erase the current project. Later, the writer may need to locate the version sent, understand the relation between the reviewed file and later revisions, or assemble a more durable record.
The stewardship stack turns this from a vague storage question into a series of small, inspectable questions.
| Question at hand-off | Stack layer | Proportionate evidence | What remains outside the answer |
|---|---|---|---|
| Can the writer keep working if the network disappears? | Access | The current draft opens on the local device. | Whether the device will survive loss or compromise. |
| Can the writer take the text to a different environment? | Custody | A documented export or a readable local file. | Whether the export retains every comment, layout feature, or history. |
| Does the tablet hold the current state? | Replication | A visible synchronization status and known conflict behavior. | Whether an earlier state can be restored. |
| Can the writer undo a catastrophic deletion? | Recovery | A separate backup with a retention policy and a restoration check. | Whether later readers can understand editorial significance. |
| Can the editor identify the reviewed text? | Provenance | A named review file, date, version note, and hand-off record. | Whether every earlier private draft should be disclosed. |
| Can the author share appropriately? | Selective disclosure | A chosen review copy and an explicit decision about comments, notes, and attachments. | A universal rule about what every author must retain. |
This scenario yields an important distinction between hand-off and archive. A hand-off is a social and editorial act. It records a specific version for a defined recipient and purpose. An archive may later hold the original file, an access derivative, descriptive context, technical information, rights information, and documented relations among materials. The first can be small and immediate; the second may demand institutional capacity, selection, and long-term commitments.
The distinction is reinforced by the Salman Rushdie archive case. Carroll’s abstract describes a literary collection composed of manuscripts and computers, where Emory University sought a holistic approach that integrated paper and born-digital material, used emulation and item-level search, and balanced donor with researcher needs.[8] The case is a useful counterweight precisely because it is not a personal workflow template. It shows how far the questions can extend once a working record becomes a research collection. Its resource-intensive institutional setting should caution against telling an individual writer to preserve every device, file, and trace.
The hand-off scenario therefore remains deliberately modest. It asks authors and editors to make current responsibilities visible, while leaving archival appraisal and long-term collection design for the context in which they become necessary.
5. The Manuscript Stewardship Matrix
The following matrix is the paper’s central instrument. It can be used by one writer, an editorial partnership, a small press, or a product team. It does not rate applications. It records a workflow’s actual commitments and unfinished questions.
| Stage | System should enable | Primary responsibility | What to check | Residual risk to name |
|---|---|---|---|---|
| Active drafting | Reliable access to the current working copy under ordinary interruption. | Writer; product steward where relevant. | Can the manuscript be opened and edited when the service or network is unavailable? | Device loss, damage, theft, local compromise. |
| Cross-device work | Known replication and conflict behavior. | Writer and collaborators. | Which copy is current? What occurs when edits diverge? | Silent overwrite, conflict, lag, incomplete synchronization. |
| Recovery planning | Separate, protected, testable recovery state. | Writer or organization with an assigned owner. | Can a deleted, corrupted, or compromised state be restored in practice? | Untested restore, shared failure mode, insufficient retention. |
| Editorial hand-off | A reviewable copy with a stated relationship to the working record. | Writer and editor. | Is the sent file identifiable, dated, and described by purpose? | Confusion among reviewed, revised, submitted, and published states. |
| Longer-term retention | A deliberate export, context note, and a future review or transfer point. | Writer, publisher, archive, or designated steward. | What needs to remain usable, and who will maintain it? | Format dependency, undocumented rights, unclear succession. |
| Selective sharing | A constrained release process for drafts, comments, and collaborator material. | Writer with collaborators and publisher as applicable. | What does the recipient need, and what should remain private? | Oversharing, unjustified monitoring, loss of explanatory context. |
The word primary in the third column matters. A system can support a responsibility, but it cannot remove it from the world. An application may offer automatic backup. The person or organization using it still needs to know what it covers, whether it has been tested, how long it retains prior states, whether it shares a failure mode with the primary copy, and who can initiate restoration. A cloud service may hold an off-site replica. A writer still needs to know whether the material can be retrieved at exit, what rights apply, and whether a review copy should travel elsewhere.
CISA’s guidance offers a useful discipline without becoming a mandate: identify what matters, separate recovery copies from primary systems, protect them, and test that restoration works.[5] NIST adds that organizations should choose recommendations relevant to their particular needs rather than attempting an indiscriminate checklist.[6] The teaching implication is proportion, not maximalism. A novelist does not need to imitate an enterprise. A small press should not ignore recovery simply because it lacks an enterprise team.
The matrix also makes it harder to make vague claims about privacy. Local access may reduce some categories of provider dependency, but a local device can be stolen, compromised, or shared. Remote storage may expose material to service terms, access controls, or provider operations, but professionally managed storage can also provide redundancy and integrity processes that an isolated device cannot. The task is to identify which exposure matters at which stage—not to call one location intrinsically private.
6. Local-first as a situated option
A local-first orientation is valuable because it reverses a common default. If the working copy resides on the writer’s device and can be used without a necessary service round-trip, the writer has more immediate agency during an outage, while traveling, or when choosing to leave a service. Ink & Switch connects this arrangement with local responsiveness, optional networking, cross-device use, longevity, privacy, and user control.[1] For working manuscripts, the basic attraction is intelligible: the work at hand is not merely a remote permission.
But the manuscript stewardship stack resists converting that attraction into a verdict. A local copy is an access and custody fact. It does not tell us whether the file is replicated, whether separate recovery exists, whether the writer understands the export, whether an editor can review it, whether sensitive comments are protected, or whether a successor can interpret it. The same local agency that permits a writer to copy and organize work freely can place more maintenance and security work on the writer.
The Digital Preservation Coalition makes the relevant proportion explicit. It describes creators as the first line of defense for valuable digital information while cautioning that most individuals cannot be expected to make an unlimited long-term commitment beyond their practical needs. It recommends actions that improve current continuity—supported tools, clear naming and versions, storage and backup, and planned transitions—while emphasizing dialogue and responsibility where longer-term preservation becomes relevant.[7]
This is a better way to speak about local-first design. It may expose and support authorial custody. It may make offline work and export easier. It may reduce some forms of immediate dependence. Whether it achieves those outcomes depends on particular technical and social arrangements, and whether the remaining stack layers are carried elsewhere.
7. Counterpoint: managed infrastructure can be stewardship
The alternative to romantic localism is not surrender. Managed cloud infrastructure can provide real stewardship functions. The Digital Preservation Coalition notes potential benefits including automated replication across locations, professionally managed storage, integrity checking, specialized preservation procedures, workflows, and service agreements.[4] For a small organization without dedicated infrastructure, these may be meaningful capabilities rather than mere convenience.
The same guidance provides the conditions that make this a stewardship question rather than a brand preference. Cloud services involve contract management, vendor stability, rights, permissions, privacy, security, budgeting, exit planning, monitoring, and audit. The Coalition specifically stresses that archival contracts and service-level arrangements should be evaluated over the long term and that effective exit strategies should be explicit and tested.[4]
The same general structure applies at a smaller scale. A writer need not negotiate an archival service-level agreement to ask: Can I export my current material? What form does the export take? If access ends, what remains available? Do I know which copy is held remotely? What happens to private comments or collaborator material? What can I restore, and what merely syncs? Those questions are not hostile to managed infrastructure. They are the beginning of accountable use.
This is why the manuscript stewardship stack is not a local-versus-cloud scorecard. A writer can have strong local access and poor recovery. A small press can use a managed service with good replication and weak exit planning. An editor can hold a clearly labeled review copy while the writer retains the working record. A future archive can receive a carefully selected package while private drafts remain restricted. The responsible arrangement is the one in which the material purpose, the responsible party, the evidence, and the unresolved risks are clear.
8. Boundaries and design implications
The stack yields four design implications, each bounded by what it does not prove.
First, systems should make distinct states visible. A person should not have to infer whether a current document is local, merely cached, synchronized, backed up, or exported. Visibility does not guarantee safety, but it helps a user assign responsibility accurately.
Second, recovery should be legible as a practice. A promise that material is “protected” is weak if the user cannot identify what is recoverable, from where, after what kind of failure, and how restoration is tested. This does not require a universal backup rule. It requires a way to inspect the actual arrangement.
Third, hand-off deserves its own record. A review copy is not simply another duplicate. It is a version released to a particular person for a particular editorial purpose. A modest naming, version, and context note can preserve this relationship without turning every writing workflow into a surveillance log.
Fourth, preservation must remain proportionate. A creator may need practical continuity for years without becoming a repository. A literary archive may later require more: selection, rights work, format analysis, access planning, original files, derivatives, provenance, and restrictions. The working manuscript’s stewardship stack prepares a person to recognize that transition; it does not replace the appraisal and institutional work it can require.
A local manuscript is not a guarantee. It is a condition of possible agency whose value depends on the surrounding responsibilities made visible.
This paper does not rank applications, recommend Wexley Pro, offer legal advice about ownership, certify privacy or security, or equate local possession with preservation. It asks a narrower and more durable question: when a manuscript matters, who can work with it, move it, recover it, explain it, and disclose it appropriately? The Manuscript Stewardship Matrix makes that question usable before the writer needs an archive—and before a simple word such as saved has done too much conceptual work.
Limitations
This is a conceptual teaching manuscript, not a comparative systems benchmark, user study, legal opinion, or preservation certification. Its central hand-off case is constructed to make documented distinctions tangible; it is not evidence that a named platform behaves in a stated way. The local-first source is a design-oriented research essay whose ideals are not empirical guarantees. Institutional preservation guidance may exceed the resources of individual writers and small publishers; it is used here for principles of responsibility and proportion rather than as a personal compliance program. The Rushdie archival case is included only at the level of its inspected abstract and should not support claims beyond that description. Finally, the stack separates functions for teaching clarity. In practice, a single workflow may combine them, and the appropriate balance depends on the sensitivity, scale, collaborators, legal setting, and future value of a manuscript.
References
[1] Martin Kleppmann et al., “Local-first software: You own your data, in spite of the cloud,” Ink & Switch, 2019.
[2] Library of Congress, “Personal Digital Archiving.”
[3] National Digital Stewardship Alliance, “Levels of Digital Preservation,” Version 2.1, 2026.
[4] Digital Preservation Coalition, “Cloud Services,” Digital Preservation Handbook.
[5] U.S. Cybersecurity and Infrastructure Security Agency, “Back Up Business Data.”
[6] National Institute of Standards and Technology, “Protecting Data from Ransomware and Other Data Loss Events,” 2020.
[7] Digital Preservation Coalition, “Creating Digital Materials,” Digital Preservation Handbook.
[8] Laura Carroll, “A Comprehensive Approach to Born-Digital Archives,” Archivaria 72 (2011). Abstract inspected.