{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-08-21T09:56:17.837Z"},"content":[{"type":"documentation","id":"14afa067-ac72-42f3-95ec-2a33eecac6ee","slug":"research-data-preservation-format-obsolescence","title":"Will You Be Able to Open Your 2026 Research Data in 2036? A Preservation Plan for Interview Archives","url":"https://www.koji.so/docs/research-data-preservation-format-obsolescence","summary":"Research data decays in three independent ways: bit-level loss, format obsolescence, and context loss. Backups address only the first. A preservation plan names a designated community, sets a format policy against the Library of Congress sustainability factors, keeps at least two copies, schedules fixity checks, and names the transformational properties that must survive migration. Koji reduces the burden by storing transcripts as structured text with the brief and question set attached, and by exporting whole studies as portable JSON.","content":"**Short answer:** Your interview data will almost certainly still exist in 2036. Whether you can still *use* it is a different question, and it depends on decisions you make now. Three things decay independently: the bits (storage failure), the format (nothing can render it), and the context (nobody can interpret it). Backups solve only the first. A research preservation plan solves all three by choosing sustainable formats, checking fixity on a schedule, and storing enough surrounding information that a stranger can read a transcript without calling the person who ran it. Koji reduces the burden by keeping transcripts as structured text with the study brief attached, and by exporting the whole study - brief, respondents, transcripts, report summary - as portable JSON you can hold yourself.\n\nMost teams treat this as a backup problem. It is not. A backup is a promise that the bytes will come back. Preservation is a promise that the bytes will still mean something when they do.\n\n## The three things that decay, and only one of them is the bits\n\nArchivists separate these deliberately, because the countermeasures are different and a team that has solved one usually believes it has solved all three.\n\n**1. Bit-level loss.** Storage media fail, files get truncated on copy, a sync job silently drops a directory. This is the failure everyone plans for, and it is the least likely to hurt you, because cloud object storage is durable and your provider is already replicating.\n\n**2. Format obsolescence.** The file is byte-perfect and no available software will render it. This is the failure that actually bites research teams, and it arrives through a side door: a proprietary transcript format from a vendor you no longer pay, a video codec that needed a plugin, an analysis project file from a tool that shut down.\n\n**3. Context loss.** The file opens, the words are all there, and the reader cannot tell what was being asked, who the participant was, which product version they were describing, or why the study was run. Nothing is technically broken. The record is simply no longer interpretable.\n\nThe Open Archival Information System reference model, published by the Consultative Committee for Space Data Systems as [CCSDS 650.0-M-2](https://public.ccsds.org/Pubs/650x0m2.pdf) and adopted as ISO 14721, names the standard everything else is measured against. Information is preserved only if it stays **Independently Understandable**, defined as \"sufficiently complete to allow it to be interpreted, understood and used by the Designated Community without having to resort to special resources not widely available, **including named individuals**.\"\n\nThat last clause is the one worth pinning above a research repository. If understanding your 2026 transcript requires a conversation with the researcher who ran it, the transcript is not preserved. It is merely stored, and it is one resignation away from being unreadable.\n\n## The seven sustainability factors, applied to research data\n\nThe Library of Congress maintains a [set of sustainability factors](https://www.loc.gov/preservation/digital/formats/sustain/sustain.shtml) for judging whether a format is fit for long-term keeping. They were written for national collections, they apply cleanly to interview archives, and they turn a vague worry into a checklist you can run against your current stack in an afternoon.\n\n| Factor | The question to ask about your research data |\n| --- | --- |\n| **Disclosure** | Is the format fully specified in public documentation, with tools that can validate a file independently of the vendor that wrote it? |\n| **Adoption** | Is the format widely used outside your vendor? Widely adopted formats attract migration tools without anyone funding them. |\n| **Transparency** | Can a human open the file in a plain text editor and see the content? UTF-8 text in natural reading order is the high-water mark here. |\n| **Self-documentation** | Does the file carry its own descriptive and technical metadata, or does all the meaning live in a separate database you may not export? |\n| **External dependencies** | Does rendering require specific software, a plugin, a licence server, or a live network connection? |\n| **Impact of patents** | Could licensing terms make future transcoding expensive or legally awkward? |\n| **Technical protection mechanisms** | Is the content encrypted or tied to a device in a way that blocks you from copying and migrating it? |\n\nThe Library states the hard rule plainly: \"No digital format that is inextricably bound to a particular physical carrier is suitable as a format for long-term preservation.\" Read \"physical carrier\" as \"one vendor's running system\" and you have the research version. A transcript that exists only inside a tool's web interface, retrievable only while your subscription is active, fails the test no matter how good the tool is.\n\nScore your own stack. Interview audio in a common codec scores well on adoption and disclosure. A transcript rendered only as a web page scores badly on transparency and self-documentation. A vendor's proprietary project file usually fails four of the seven at once.\n\n## The migration ladder: four rungs, and the one where meaning starts to leak\n\nPreservation is not a single act. OAIS defines a ladder of migration types, ordered by how much they disturb the object, and the ordering matters because your risk changes completely at the third rung.\n\n1. **Refreshment.** Copy to new media. The bits are identical; nothing about the object changes.\n2. **Replication.** Copy with no change to packaging or content. Still lossless in every sense that matters.\n3. **Repackaging.** The packaging changes but the content does not. Moving files into a new container, a new file system, a new archive structure.\n4. **Transformation.** The content itself is altered. OAIS gives the example of converting character codes to Unicode.\n\nRungs one and two are chores. Rung four is a decision with consequences, and OAIS splits it further into **Reversible** and **Non-Reversible Transformation**. A reversible transformation lets you reconstruct the original exactly. A non-reversible one does not, which means you must decide in advance which properties are allowed to change and which must survive. OAIS calls those the **Transformational Information Properties**: the characteristics whose preservation proves the transformation kept the information intact.\n\nFor research data, name yours explicitly before you migrate anything. Realistic candidates: speaker attribution, turn boundaries, timestamps, the exact wording of the question that prompted each answer, and the link from a quote back to its position in the full transcript. If a migration preserves the words but loses which speaker said them, the transformation destroyed evidence while appearing to succeed. Every quote in the resulting archive becomes unattributable, and no error message tells you.\n\n## Fixity: how you find out you lost something\n\nFixity is the archival term for the assurance that a file has not changed. OAIS defines **Fixity Information** as \"the information which documents the mechanisms that ensure that the Content Information object has not been altered in an undocumented manner.\"\n\nThe mechanism is a checksum: a digital fingerprint where the smallest change to a file changes the fingerprint completely. The [Digital Preservation Coalition Handbook](https://www.dpconline.org/handbook/technical-solutions-and-tools/fixity-and-checksums) gives the operational detail most teams get wrong:\n\n- **Generate on ingest, not later.** A checksum created after corruption has already happened faithfully records the corrupted state.\n- **Re-check on a schedule.** As a guideline, hard-drive based systems roughly every six months, tape annually. Comparing each copy against its known-good reference value and repairing mismatches from a good copy is called data scrubbing.\n- **Fixity is only useful with more than one copy.** A checksum tells you a file is broken. It cannot fix it. Repair requires a second copy that still matches.\n- **MD5 is sufficient for accidental loss.** Reach for SHA-256 when you need to demonstrate resistance to deliberate tampering, which is the case if the material may become evidence.\n\nThere is a subtlety here that connects directly to the rest of your archive. A deliberate migration also changes the checksum. The checksum cannot distinguish \"storage corrupted this file\" from \"we transcoded this file on purpose last March.\" Only a written record of the authorised change can tell those apart, which is why preservation systems log every transformation and why an archive without such a log eventually cannot explain its own contents.\n\n## What a research preservation plan actually contains\n\nSix elements, and it fits on one page.\n\n1. **A designated community.** OAIS requires you to name who must be able to understand the material, because the standard is meaningless otherwise. For most teams the honest answer is \"a product manager or researcher at this company, two to five years from now, who was not involved in the original study.\" Write it down. It determines how much explanation you owe.\n2. **A format policy.** For each artefact type, the format you keep for the long term. Transcripts as UTF-8 text or JSON. Audio in a widely adopted, openly documented codec. Reports as both the rendered document and the structured data behind it.\n3. **Copies and locations.** At least two, in different systems, at least one outside your primary research tool. If your only copy of everything lives in one vendor's account, you have a single point of failure that a billing lapse can trigger.\n4. **A fixity schedule.** Who runs the check, how often, and what happens when one fails.\n5. **Named transformational properties.** The list from the previous section, written before your first migration rather than during your first panic.\n6. **A review trigger.** Preservation plans go stale. Review on vendor change, on a format falling out of support, and otherwise annually.\n\n## Where the risk concentrates for research teams\n\n**Voice and video are the fragile assets.** They are large, they are stored in codecs chosen for streaming rather than for keeping, and they often live with the vendor rather than with you. They are also the artefacts with the highest evidential value, because a recording is the only thing that can settle a dispute about what a participant actually said. If you preserve one thing well, preserve the audio and a faithful transcript of it.\n\n**Analysis artefacts are the ones nobody exports.** Codebooks, tag taxonomies, and the mapping from theme to quote frequently exist only as application state. When the tool goes, the reasoning goes with it, and you are left with transcripts and no record of what anyone concluded from them.\n\n**Vendor exit is the most common obsolescence event.** Not a codec dying over decades, but a subscription ending in ninety days. OAIS anticipates this in its own list of responsibilities, requiring archives to preserve information \"against all reasonable contingencies, including the demise of the Archive.\" Treat every research tool as an archive that may one day demise, including the one you are happy with.\n\n## How Koji lowers the preservation burden\n\nKoji is built so the durable artefacts are the ones that leave the building easily.\n\n- **Transcripts are structured text, not a rendered view.** Every AI-moderated interview, voice or text, produces a full timestamped transcript with speaker attribution and each answer bound to the question that prompted it. That binding is one of the transformational properties you would otherwise have to reconstruct by hand.\n- **Structured questions preserve their own meaning.** Koji's six structured question types - open_ended, scale, single_choice, multiple_choice, ranking, and yes_no - carry their response options and scale definitions in the data. A scale answer of \"4\" exported from a survey tool is a number with no scale attached. The same answer in Koji arrives with the question, the scale, and the labels, which is exactly the self-documentation the Library of Congress factor asks for.\n- **Whole-study export you control.** Through the API and the MCP tool `koji_export_data`, you can export the research brief, the respondent list, full transcripts, and the report summary as structured JSON, then put that copy wherever your policy says the second copy lives. Transcripts page in batches, so a large study exports reliably rather than timing out.\n- **The brief travels with the data.** Because Koji generates the study from a research brief, the purpose, the methodology, and the exact question set are stored alongside the answers rather than in someone's notes. That is the context layer, captured automatically at the moment it is cheapest to capture.\n\nThe comparison with a traditional stack is not subtle. A study run across a survey tool, a scheduling tool, a recording tool, and a slide deck leaves five partial records in five systems, each with its own export path and none carrying the others' context. A study run in Koji leaves one record that exports whole.\n\n## A thirty-minute starting point\n\nPick your three most consequential studies from the last two years. For each, try to answer four questions using only what is stored, without asking a colleague: What was the research question? Who were the participants? What version of the product were they describing? Where is the raw audio?\n\nWhatever you could not answer is your context gap, and it is almost always larger than the technical gap. Fix that first. Then run the seven sustainability factors against your current formats, and set a fixity schedule for the copies you control. That is a preservation plan, and it is genuinely a morning's work.\n\n## Frequently asked questions\n\n### Is a backup the same as digital preservation?\n\nNo, and the difference is the single most common misunderstanding in this area. A backup protects against bit-level loss and usually has a short retention window measured in weeks. Preservation protects against format obsolescence and context loss over years, and it requires decisions a backup system never makes: which format to keep, which properties must survive migration, and how much surrounding information to store. A perfect backup of an unreadable file is an unreadable file.\n\n### How long should we plan to keep interview data?\n\nPreservation planning and retention policy answer different questions and should be written separately. Retention answers how long you are permitted and required to keep personal data, which is a legal question covered in our guide to [research data retention and deletion](/docs/research-data-retention-deletion). Preservation answers whether the material you have decided to keep will still be usable at the end of that period. A five-year retention policy with no preservation plan routinely produces year-five files nobody can open.\n\n### What format should we keep transcripts in?\n\nPlain UTF-8 text or JSON, both of which score well on transparency and self-documentation. JSON is preferable for research because it holds speaker attribution, timestamps, and the question-to-answer binding as structured fields rather than as typographic convention. Keep the rendered document too if people read it that way, but treat the structured version as the preservation copy.\n\n### Do we need checksums if our data is in cloud storage?\n\nCloud object storage is highly durable and already handles most bit-level risk, so checksums are not your first priority. They become worthwhile once material moves between systems, because that is where truncation and partial copies happen, and they become necessary when you may have to demonstrate that a recording is unaltered. If your research data could ever support a marketing claim or a legal position, generate checksums on ingest and record them alongside the files.\n\n### What happens to our data if we stop using a research platform?\n\nThat depends entirely on whether you exported while you still had access, which is why export should be routine rather than an exit task. With Koji you can export briefs, respondents, transcripts, and report summaries as JSON at any time through the API or MCP, so a copy under your own control is a scheduled job rather than a scramble. The general principle applies to every vendor: if you cannot produce a current export today, you do not yet own your research data.\n\n### Does preserving old research conflict with insight decay?\n\nThey address different objects. Insight decay is about whether a *conclusion* still holds, and the answer is often no, as covered in [how long user research stays valid](/docs/research-refresh-cadence). Preservation is about whether the *evidence* remains usable, and there the answer should always be yes. Preserved raw data is what lets you re-examine an old conclusion rather than simply distrusting it, and it is what makes reuse for a new question possible at all.\n\n## Related Resources\n\n- [Structured Questions: The Complete Guide](/docs/structured-questions-guide) - the six question types and the response data each one produces.\n- [Exporting Research Data from Koji](/docs/exporting-research-data) - CSV, JSON, transcript access, and API export paths.\n- [Research Data Retention and Deletion](/docs/research-data-retention-deletion) - how long you are allowed and required to keep interview data.\n- [Research Provenance and Authenticity](/docs/research-artifact-provenance-authenticity) - proving an interview, quote, or report is genuine.\n- [The Study-Level Description](/docs/study-level-description-research-findability) - the description layer that makes an archive navigable.\n- [How to Build a UX Research Repository](/docs/research-repository-guide) - structuring the repository these policies protect.\n","category":"Research Operations","lastModified":"2026-08-21T03:25:48.491759+00:00","metaTitle":"Research Data Preservation: Format Obsolescence and Interview Archives (2026)","metaDescription":"Why backups are not preservation: format obsolescence, fixity checks, and the context layer that decides whether your 2026 interview data is usable in 2036.","keywords":["research data preservation","format obsolescence","interview data archiving","digital preservation research","fixity checksum research data","long term research storage"],"aiSummary":"Research data decays in three independent ways: bit-level loss, format obsolescence, and context loss. Backups address only the first. A preservation plan names a designated community, sets a format policy against the Library of Congress sustainability factors, keeps at least two copies, schedules fixity checks, and names the transformational properties that must survive migration. Koji reduces the burden by storing transcripts as structured text with the brief and question set attached, and by exporting whole studies as portable JSON."}],"pagination":{"total":1,"returned":1,"offset":0}}