Long-term data portability and archival — how do authors leave WorldScript with everything that matters?

[qnbs]

Why this exists

Authors may keep projects for decades, move between tools, or need to recover work after a product disappears. This Discussion explores how an author can leave WorldScript with everything that matters, without vendor lock-in or a second silent authority.

Product decision space

Consider durable project export, a human-readable fallback, and a machine-readable canonical package containing manuscript text, scenes, entities, notes, research, assets, compile settings, snapshots, and history where appropriate.

The package should explain plugin and project-data boundaries. RAG source data should be distinguishable from regenerable indexes. Encrypted export options, future-version handling, documented schema, checksums/integrity evidence, and export-before-destructive-recovery all deserve explicit contracts.

A useful archive should remain understandable if WorldScript disappeared. It should make clear what is portable, what is transformed or lossy, how to inspect it without the application, and how to verify that a restore or migration did not silently omit data.

Context only

Discussions and Issues #481, #482, #521, #553, and #445 provide local files, storage/recovery, export, project-schema admission, and future protected-storage context. They remain implementation authorities. No engineering-Issue crosslinks are added from this Discussion.

Role perspectives

Role-perspective note: The viewpoints below are maintainer-curated, AI-assisted design lenses. They are not separate community members, votes, user testimony, or evidence of consensus.

• ✍️ Author owning long-lived work: keep the manuscript and meaningful project context readable and recoverable.
• 🗄️ Archivist/data portability: use documented formats, stable identifiers, checksums, and inspectable packages.
• 🧪 Schema/migration: preserve unknown data where safe, version transformations, and make omissions explicit.
• 🔐 Encryption/privacy: offer protected export choices without making recovery depend on an opaque or irrecoverable secret.
• 🧭 Product scope: define a durable core and clear boundaries instead of promising every plugin or proprietary format.

Questions

• What must remain readable if WorldScript no longer exists?
• Which project data belongs in the canonical package versus a human-readable fallback?
• How should snapshots, history, compile settings, assets, research sources, and regenerable indexes be represented?
• Which checksums, manifests, and import reports would make an archive trustworthy?
• When should an encrypted export be offered, and how should key loss be handled?
• What should happen when opening a package from a future schema version?
• Which plugin data can be portable, and how should unsupported data be disclosed?
• What is the minimum archive a long-lived author should be able to create before destructive recovery?

Relationship to implementation

This is long-term portability and archival design. It does not create a second authority, promise universal plugin or proprietary-format portability, or change #481, #482, #521, #553, or #445 priority, roadmap admission, acceptance criteria, or sequencing.