> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Build a searchable media archive description: >- Turn a small set of recordings into timestamped transcripts, a scene list and a segment index. Run the recipe the workflow declares, then check every artifact against a six-file fixture. route: /docs/compute/examples/media-archive page_id: docs-compute-examples-media-archive page_type: tutorial content_layer: guided documentation surface_profile: guided_docs audience: Teams with a media library they cannot currently search voice: D reader_question: How do I turn a folder of recordings into transcripts, scenes and an index? primary_action: Run a six-file archive test source_locale: en-US source_status: APPROVED source_version: docs-compute-examples-media-archive-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## What you get Three artifacts per accepted asset, plus the standard bundle files around them. - A timestamped transcript, in the transcript format the workflow declares. - A scene list for each video asset, with a start and end time per scene. - A segment index keyed by your own asset identifier, so you can search it. Each row carries `lithi_status`, `lithi_confidence` and `lithi_evidence`. The evidence is a time range in the source, not a summary of it. ## What you need Six files and a manifest. That is small enough to check by hand and large enough to show a mixed outcome. ```text asset_id,path,duration_seconds,language ARC-0001,clips/board-review.mp4,412,en ARC-0002,clips/site-walk.mp4,190,en ARC-0003,clips/handover.mov,733,en ARC-0004,audio/standup-14.m4a,301,en ARC-0005,audio/interview-raw.wav,1180, ARC-0006,clips/damaged-export.mp4,0,en ``` `asset_id` is your item identifier. Declare it as `item_id_field` so every outcome points back to a row you own. Row five leaves the language blank on purpose. Row six is a broken export, and should fail rather than return an empty transcript. ## Run it 1. Inspect locally first: `lithi media inspect ./archive-fixture`. It reads duration, container and track layout on your machine, before anything is sent. 2. Read the recipe: `lithi workflow explain `. This lists the declared stages and the maximum item count for that workflow. 3. Ask for a quote: `lithi quote --workflow --input ./archive-fixture/manifest.csv`. The quote states a maximum charge and an expiry, and authorizes nothing. 4. Approve it. Approval is a separate act, taken by whoever holds spend authority on the account. 5. Submit with `lithi batch submit`, against the approved quote. 6. Track with `lithi status `, then `lithi result download ` once it is terminal. Use the multi-stage workflow as declared. Do not chain stages yourself to reach a shape the descriptor does not offer: see [how multi-stage recipes are declared](/docs/compute/workflows/multi-stage). ## Read the result Open `result-manifest.json` first. It is written last and is the only marker that the bundle is complete. Part files alone never mean the run finished. Then read in this order: - `data/part-*` for accepted assets and their transcript, scene and index rows. - `failures/part-*` for the broken export, which should carry a typed code, a safe reason and a next action. - `abstentions/part-*` for the asset with no declared language, if the workflow declined rather than guessing. - `provenance.json` to confirm the input digest matches the snapshot you submitted. Four quality checks are worth doing by hand on the first run. Confirm transcript timestamps increase and cover the whole duration. Confirm each scene boundary cites a time in the source. Confirm the index resolves back to `asset_id`, not to row position. Then open two assets and compare a minute of each against the real recording. ## Where it stops This produces artifacts about your media. It does not edit, re-encode for delivery, or publish anything. It does not decide what belongs in your public catalog. It does not push results into a content system on its own, and it never contacts anyone. A person reviews the index and chooses what to do with it. Accuracy is not promised. The quality preset in force states what was checked and what was not, and the transcript's evidence is what lets you check the rest yourself. Keep your identifiers stable between runs, or the index will not merge cleanly: [give every item a stable identity](/docs/compute/inputs/item-identity).