Turn meeting recordings into cited actions

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.

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 <workflow-id> for the declared stages, parameters and item ceiling.
3. Quote it: lithi quote --workflow <workflow-id> --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 <job-id>. 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.

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.

Correctness is not promised. What you get is a citation for every claim. A person checks it in seconds, then decides who does what.