On this page
The short answer
Evaluate completeness against a task-specific list of required points established before reviewing the answer. Count whether each point is satisfied, missing, contradicted, or unresolved. A long response can remain incomplete, while a short response can be fully sufficient. Pair coverage with factual support so invented additions never compensate for missing requirements.
What to take away
- Define required points before reading outputs.
- Keep optional detail outside the coverage denominator.
- Pair point coverage with complete-task acceptance.
Sources checked . Research synthesis and Rubrex recommendations. Examples and local experiments are labeled; they are not client results.
Define requirements independently of the answer
Ragas documents factual overlap with a reference using claim-based precision and recall modes. A practical completeness review still needs a trustworthy reference describing what the user actually required; generated claims cannot define their own coverage denominator.
Extract the requested decisions, facts, constraints, exceptions, and next steps from the task contract. Separate essential points from helpful optional context. For multi-part questions, keep each requested component explicit. Do not turn every sentence in a polished reference answer into a mandatory point merely because the reference happens to include it.
Evidence: Ragas: Factual Correctness [1]
Write observable satisfaction rules
For each required point, specify evidence and acceptable alternatives. A cancellation answer might need the ordinary deadline, a stated exception, and the required account action. A vague mention that exceptions exist may not satisfy a task that asks which exception applies.
Allow equivalent wording and valid structured representations. Keep duplicated statements from counting twice. Use partial credit only where the rule can be applied consistently and where the report distinguishes it from full satisfaction. An unresolved reference should remain unresolved rather than force a candidate into a misleading pass or fail.
Work through an illustrative coverage record
Consider an invented request asking for a policy deadline, enterprise exception, and next contact. An answer supplying the deadline and exception but omitting the contact covers two of three equally weighted required points, or 66.7%. That arithmetic is illustrative, and equal weighting is a declared policy rather than a universal rule.
If the missing contact makes the workflow unusable, the task can still fail complete acceptance despite substantial point coverage. Conversely, adding three unrelated correct facts does not increase the numerator. The denominator comes from requirements, not the number of statements the model chooses to produce.
| Case or record | Expected check | Decision |
|---|---|---|
| Deadline and exception; contact absent | 2 of 3 required points covered | 66.7% coverage; task may still fail |
| Three unrelated facts added | No additional required point satisfied | Do not increase coverage |
| Equivalent wording satisfies a point | Meaning and qualification preserved | Count once as covered |
Use omissions to locate the failing stage
Compare required-point coverage on the same cases for baseline and candidate. Inspect whether omitted information was absent from retrieval, dropped during context assembly, or ignored during generation. Keep factual contradictions separate from simple omissions so the next repair targets the right cause.
Report fully accepted tasks alongside point-level coverage and severe omissions. Audit a sample of automatic completeness judgments against independent reviewers. Revisit the checklist when the product request changes, and version the new acceptance boundary rather than silently making historical answers appear more or less complete.
Limits of the evidence
The policy example and percentages are authored illustrations. No completeness evaluator was measured. Reference requirements can be incomplete or ambiguous, and claim-overlap metrics need validation against the actual task rather than automatic adoption.
Common questions
Is completeness the same as factual correctness?
No. An answer can contain only true statements while omitting the point the user needed. It can also mention every requested topic but make false claims.
Should every required point have equal weight?
Only under an explicit policy. Preserve critical blocking requirements separately when their omission cannot be offset by other coverage.
Sources & further reading
Primary sources behind this briefing. A source’s findings apply to its own study conditions; publication on arXiv does not establish peer review.
- Ragas: Factual Correctness Ragas · Living reference · Maintained documentationReviewed: claim decomposition, reference overlap, precision/recall modes and coverage settings. Accessed October 16, 2026.
Questions or corrections? Write to Rubrex. Read our editorial approach.