Classify summary errors by what failed and its downstream consequence, keeping content quality separate from record-delivery failures. A single “bad summary” label hides the difference between an invented commitment, an omitted next step, and a correct note saved to the wrong case. Each needs a different repair.
Level AI describes call summaries. Google Cloud separates summary accuracy, completeness, and adherence. The taxonomy below is an editorial review method that expands those questions into actionable labels; it is not a native scoring system or a measured vendor comparison.
Which labels should reviewers use?
| Error category | Illustrative failure | Likely review owner |
|---|---|---|
| Unsupported detail | A proposed action becomes a completed action | Content evaluation lead |
| Material omission | An unresolved investigation disappears | Workflow and QA owners |
| Attribution | A customer's statement becomes the agent's promise | Conversation reviewer |
| Uncertainty | A tentative date is presented as confirmed | Content evaluation lead |
| Structure | A required next-owner field is absent | Template owner |
| Delivery | Correct text attaches to another case | Integration owner |
The examples are constructed test cases, not observed vendor failures. Allow multiple labels where appropriate. An omitted qualification can be both a completeness problem and a consequential change in meaning.
How should severity be assigned?
Judge the effect on the downstream task, not just how much text is wrong. A small wording change may create a commitment the agent never made. A longer stylistic defect may be inconvenient without changing the case outcome. Agree on severity definitions with the teams that use the saved record.
Record the source excerpt, generated statement, corrected statement, error label, severity explanation, and reviewer. Keep “unclear from evidence” available when the conversation itself does not resolve the issue. Do not force a reviewer to invent the correct answer.
How should the team find the cause?
Check whether the source transcript preserved the relevant conversation, whether the summary instructions asked for the information, and whether the output transformed it incorrectly. A transcription error, missing instruction, and unsupported generation may produce similar-looking notes but need different interventions.
Review recurring errors by contact type and template version. Retain a reference set of resolved examples for rechecking a proposed fix. Ask a second reviewer to assess a sample of labels so the error totals do not merely reflect one person's interpretation.
How should repairs be prioritized?
Address consequential repeated errors first, while keeping denominators visible. Report affected eligible summaries and not only the count of labels. A single summary can contain several errors, so label counts are not equivalent to the proportion of contacts affected.
After a change, inspect both repaired cases and previously acceptable cases. For destination failures, use the field-mapping contract; for overall acceptance, return to after-call work evaluation.
How would reviewers label a corrected commitment?
Consider this illustrative source exchange: the customer asks for a refund; the agent says a supervisor must review eligibility and promises only to send the request. The generated note says, “Refund approved; customer will receive payment.” Label the approval as unsupported detail and the missing review dependency as a material omission. Preserve the source excerpt rather than inferring an approval from the customer's request.
| Review record | Illustrative entry |
|---|---|
| Supported replacement | Refund review requested; eligibility unresolved; supervisor is the next owner. |
| Consequence to assess | Could the next agent incorrectly treat the refund as authorized? |
| Repair test | Replay this case plus a genuine approved-refund case; the fix must distinguish them. |
| Release decision | Keep the draft under review until the authorization state is preserved. |
Count the affected summary once in the summary-error rate even when several labels apply. Separately report counts by label for diagnosis. A change that removes unsupported details by deleting every action may improve one metric while worsening completeness, so review those dimensions together without merging them into an unexplained total.
What are the limits of this taxonomy?
Sources were checked October 20, 2026. This taxonomy has not been validated as a research instrument, and no product error rate is reported. Severity depends on workflow and source clarity. Automated evaluation can help prioritize review but should not be treated as independent ground truth without checking its agreement with qualified human reviewers.