Preserve the recording before interpreting it

A recording finishes processing, and the application presents a useful summary. A week later, someone notices that a name is wrong. The transcript has already been replaced by the summary, the recording has disappeared, and correcting the name now requires finding the original speaker. The application saved storage by discarding the material needed to repair its own work.

That failure should be addressed before choosing a model. An audio-to-knowledge system needs a durable source record and a way to replace interpretations without replacing the source. Otherwise, each improvement to transcription or extraction creates an uncomfortable choice between preserving old mistakes and losing the history of previous decisions.

In August, I clarified that the audio application I was specifying should primarily analyze media after the fact. Live capture could remain available, but retrospective playback was the intended default. The resulting architecture specified that transcription failures preserve audio, extraction failures preserve transcripts, and derived knowledge remain rebuildable. Those are design requirements; the retained material does not establish a completed ingestion application.

What must survive a failed run

Register each source before processing it. Give the recording a stable identifier, record its location and permitted uses, and calculate a content hash so the system can distinguish the same bytes from a changed file. Preserve the original recording under the applicable retention policy. A filename can help a person recognize it, but a filename alone cannot establish which recording a claim used.

Time needs particular care. A recording can describe an event from last month, be published yesterday, and enter the application today. Store those dates separately when they are known. If the event date is uncertain, preserve that uncertainty rather than silently substituting the ingestion date, because a later search for current decisions may otherwise retrieve an old statement as recent evidence.

The transcript should identify the source and the transcription run that produced it. Model version, processing settings, and segment offsets belong with that run. A corrected transcript becomes a new version, while existing statements can continue to refer to the previous version until the affected interpretation has been reviewed or regenerated against the corrected passage.

An illustrative recovery exercise

Consider a hypothetical recording of a volunteer group’s planning meeting. The recording contains the sentence “The equipment order is postponed,” but the transcript drops the final word. A downstream extractor creates a claim that the order is proceeding. Nothing in this example describes a completed project or measured result.

An editor listens to the cited segment and corrects the transcript. The system records a new transcript version, marks the dependent claim for review, and reruns extraction over the affected passage. It then proposes withdrawing the earlier claim and replacing it with a supported statement about the postponement. The original recording and the old interpretation remain distinguishable throughout this process.

Now interrupt the run after transcript persistence but before claim creation. Restarting should resume from the stored transcript or deliberately create a new extraction run. It should not require capturing the meeting again. Running the same import twice should also avoid creating two unrelated source identities for identical media.

A rebuild test can go further by removing only the disposable search index in a test workspace, reconstructing it from the authoritative records, and asking the same evidence question again before inspecting its support. Verify that the answer resolves to the same recording and supporting span. The wording may differ if generation is involved; the source identity and support relationship should remain inspectable.

Preservation has permission limits

Keeping everything forever is not an acceptable default for private recordings. Retention requirements can change, a person can withdraw access, and a source can be removed. The architecture therefore needs an explicit deletion procedure that reaches transcripts, extracted claims, cached snippets, and search indexes as appropriate. Rebuildability does not authorize retaining material beyond its permitted use.

Keep processing logs useful without copying transcript content into every error message. A source identifier, failed operation, and diagnostic code may be sufficient to investigate a failure. If debugging requires content, make that a deliberate, bounded choice with its own access and retention controls.

For a first implementation, test preservation using a small recording you have permission to process. Force transcription to fail, then force extraction to fail after transcription succeeds. Check the saved source and transcript after each interruption. Finish by rebuilding the derived index and opening a result at its supporting passage; record the artifact versions that passed those checks before adding another ingestion mode.

Source notes

Based on the August 2026 audio-to-knowledge requirements and proposed architecture. The recovery exercise is illustrative and has not been reported as an executed test.