Build a searchable media archive

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.

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 <workflow-id>. This lists the declared stages and the maximum item count for that workflow.
3. Ask for a quote: lithi quote --workflow <workflow-id> --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 <job-id>, then lithi result download <job-id> 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.

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.