> ## 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: Turn meeting recordings into cited actions description: >- Get a verbatim transcript plus draft action items, each carrying the line it came from. Owners and dates stay marked as uncertain, and nothing is sent on your behalf. route: /docs/compute/examples/meeting-intelligence page_id: docs-compute-examples-meeting-intelligence page_type: tutorial content_layer: guided documentation surface_profile: guided_docs audience: Teams who record meetings and lose the follow-ups afterwards voice: D reader_question: How do I get reliable action items out of a meeting recording? primary_action: Run a four-meeting test source_locale: en-US source_status: APPROVED source_version: docs-compute-examples-meeting-intelligence-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 Two things, kept apart on purpose. - A verbatim timestamped transcript, with a speaker label per turn. This is the record. - A set of draft action items derived from it. Each one is a draft, not a decision. Every action item carries `lithi_evidence`: the timestamp range and the transcript line it came from. An action with no citation is a defect, and you should treat it as one. It also carries `lithi_confidence`, which is where owner and date uncertainty shows up. ## What you need Four recordings and a manifest. Four is enough to see a clean meeting, a crowded one and a failure. ```text meeting_id,path,recorded_at,participant_count MTG-2041,calls/weekly-ops.m4a,2026-08-04T09:00Z,5 MTG-2042,calls/vendor-review.m4a,2026-08-05T14:30Z,3 MTG-2043,calls/planning-long.m4a,2026-08-06T10:00Z,9 MTG-2044,calls/dropped-line.m4a,2026-08-07T16:15Z,2 ``` Declare `meeting_id` as your `item_id_field`. Confirm each recording is one you are permitted to process, and set the data profile that matches. Recording four cuts out halfway, so it should fail or abstain rather than invent the missing half. ## Run it 1. Inspect locally: `lithi media inspect ./meeting-fixture`. Check duration and channel count before anything is sent. 2. Read the workflow: `lithi workflow explain ` for the declared stages, parameters and item ceiling. 3. Quote it: `lithi quote --workflow --input ./meeting-fixture/manifest.csv`. The quote gives a maximum charge and an expiry, and starts nothing. 4. Approve the quote as a separate act. Nothing runs until someone with spend authority decides. 5. Submit with `lithi batch submit` against that approved quote. 6. Track with `lithi status `. `PARTIAL` is a normal ending when one meeting fails. ## Read the result Wait for `result-manifest.json`, then work through the bundle by kind. `data/part-*` holds the accepted meetings. Read the transcript rows first and the action rows second. For each action, open the cited timestamp in the transcript and confirm the words support it. Three checks decide whether you can trust the run: - Does every action item resolve to a real transcript line? - Where an owner was assigned, does someone actually say it? An inferred owner should show low confidence, not a confident name. - Where a date is relative, like "next Thursday", is it marked uncertain rather than resolved to a calendar date? `abstentions/part-*` is the healthy place for an unclear owner or date. Read it as the workflow declining to guess, which is what you want. `verification.json` states what the quality preset actually checked: see [what verification evidence proves](/docs/compute/workflows/verification-evidence). ## Where it stops You get drafts. Nothing leaves the account, and nothing is scheduled, assigned or emailed on your behalf. The transcript is a record of what was said, not a ruling on what was agreed. Two people can say contradictory things in one meeting, and both lines will appear. Disagreement between verifiers is preserved rather than resolved: [how failures, abstentions and disagreements are separated](/docs/compute/results/failures-abstentions-disagreements). Correctness is not promised. What you get is a citation for every claim. A person checks it in seconds, then decides who does what.