> ## 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: Measure call quality without one blunt score description: >- Report talk time, interruptions and issue flags as separate measures, each with the audio evidence behind it. Use a bounded, permitted recording set and read every measure on its own. route: /docs/compute/examples/call-quality page_id: docs-compute-examples-call-quality page_type: tutorial content_layer: guided documentation surface_profile: guided_docs audience: Support and sales leads reviewing recorded customer calls voice: D reader_question: How do I review recorded calls fairly, without a single opaque score? primary_action: Run a five-call review test source_locale: en-US source_status: APPROVED source_version: docs-compute-examples-call-quality-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 Four measures per call, reported separately and never merged into one number. - Talk time, split by speaker, as durations and shares of the call. - Interruptions, each with the time it happened and who spoke over whom. - Issue flags against the rubric you supply, such as a missing disclosure. - Evidence for each of the above, as a timestamp range in the recording. There is no overall grade. One number cannot be checked, appealed or explained to the person being reviewed, so this example does not produce one. Weight the four measures yourself if you need a ranking, and keep the weights visible. ## What you need Five recorded calls you are permitted to process, and a manifest. Check the permission before the audio, not after. ```text call_id,path,duration_seconds,permission_ref,channel_layout CQ-1101,calls/support-a.wav,364,CONS-2026-08-01,stereo CQ-1102,calls/support-b.wav,221,CONS-2026-08-01,stereo CQ-1103,calls/sales-a.wav,905,CONS-2026-08-02,stereo CQ-1104,calls/sales-b.wav,478,CONS-2026-08-02,mono CQ-1105,calls/support-c.wav,143,CONS-2026-08-03,stereo ``` `call_id` is your `item_id_field`. `permission_ref` points at your own record of the permission; it is a reference, not the consent document. Set the data profile that matches what you are allowed to send. Row four is mono, so speaker separation is harder and confidence should drop. ## Run it 1. Inspect locally: `lithi media inspect ./call-fixture`. Confirm the channel layout, because two-channel audio separates speakers far more reliably. 2. Read the workflow with `lithi workflow explain `, and read its parameters. The issue rubric is a parameter you supply, not a fixed list. 3. Quote it: `lithi quote --workflow --input ./call-fixture/manifest.csv`. The quote gives a maximum charge and an expiry, and authorizes nothing. 4. Approve the quote separately, then submit with `lithi batch submit`. 5. Track with `lithi status ` and download when terminal. Start on five calls, not five hundred. You are testing whether the measures match what you hear before you scale the set. ## Read the result Open `result-manifest.json` first, then read `data/part-*` one measure at a time. Take three interruptions at random and play the cited seconds. If the audio does not show an overlap, the measure is wrong and the rubric or the channel layout is the usual cause. Do the same for two issue flags. Then compare talk-time shares against the mono call. A lower `lithi_confidence` there is correct behavior, not a fault. `verification.json` states what the preset checked, and `abstentions/part-*` holds calls the workflow declined to judge. An abstention on a noisy line is better than a confident flag against a person: see [how a rubric is defined and versioned](/docs/compute/workflows/rubrics). ## Where it stops These are measures, not judgments about a person. Nothing is written to a performance record, and no one is notified. The rubric is yours, so the issue flags are only as good as the rubric you wrote. A flag says a phrase was present or absent at a timestamp. It does not say the call went badly. Send only what you are permitted to send, and keep the permission record on your side: [choose the data profile that matches your permission](/docs/compute/security/data-profiles). A person reviews the evidence and decides what, if anything, happens next.