Check an AI summary against its source for missing conditions, exclusions and dates, using an exception ledger that shows which omissions change your decision.
Direct answer: Check the original document for conditions that change who a rule applies to, when it applies and what must happen first, then compare each condition with the summary. Record the source passage and the action its omission could change. If an important exception is missing, correct the claim and recheck other statements built on it before sharing or acting on the summary.
A summary can contain no obviously false sentence and still mislead you. “Travel costs are reimbursed” may be true within a policy, but incomplete if approval must be obtained before booking. The omitted condition changes what a reader should do.
This is a problem of coverage as well as factual accuracy. The parent guide, A Useful AI Workflow for Focused Knowledge Work, explains why evidence must stay attached to claims. Here, use the exception ledger, an editorial checking method that makes decision-changing conditions visible instead of relying on a general request to “check the output”.
Applies to: summaries of documents you can inspect in full, such as guidance, research reports and internal procedures. The policy example below is fictional and does not state real employment or tax rules.
Fix the source before inspecting the summary
Save or identify the exact document version that produced the summary. Record its date and any appendices or linked rules that form part of the instruction. If the source changes halfway through review, you cannot tell whether a mismatch is an omission or a revision.
Open the document independently of the AI conversation. Confirm that you can read the relevant text, footnotes and tables yourself. If a scan has been converted to text, compare a representative section containing numbers and conditions against the visible page before relying on the conversion.
Application support for a file extension does not establish complete interpretation of every element inside it. OpenAI's file-upload documentation, for example, distinguishes text retrieval from account-dependent handling of visual content. Check the actual application and plan instead of assuming that an accepted PDF was fully understood.
Use an authorised local copy or an approved service for this review. Do not upload confidential material to another tool simply to obtain a second opinion. You can build the ledger in an ordinary document or spreadsheet you already use.
Build the exception ledger from the original
Create one row for each condition that could alter the reader's decision. Keep four fields: source location, condition, affected summary claim and consequence if omitted. This is a record of reasoning, not a proprietary template or formal assurance standard.
Start with the original text, not the summary. If the summary becomes your checklist, an omitted subject can remain invisible throughout the review. Scan the document's structure for eligibility, exclusions, effective dates, approval requirements and definitions before deciding which conditions matter.
Search can help locate words such as “unless”, “except”, “only”, “before”, “subject to” and “does not apply”. These are clues, not a complete detection method. A table heading, footnote or definition can impose a condition without using any of them.
For each candidate, ask whether a reader would take a different action if this condition were absent. If yes, keep it in the ledger. If the missing detail merely repeats an example and changes nothing material, it may be an acceptable compression.
Keep the condition attached to its claim
Do not collect exceptions in a paragraph that readers must mentally reconnect with several different rules. Attach approval requirements to the spending they govern and date limits to the provision they qualify.
Also distinguish permission from obligation. “Employees may request an advance” should not become “employees receive an advance”. Check the actor as well: a manager's responsibility to approve does not mean an employee can approve their own claim.
NIST's Generative AI Profile describes outputs that diverge from inputs and confidently present incorrect information. That supports treating an AI summary as something to verify. It does not provide an omission rate for your document or establish that this ledger guarantees completeness.
Work through a fictional travel policy
Imagine a small organisation's travel policy with eight decision-changing conditions. All rules and figures in this example are invented for explanation.
| Original condition | Summary treatment | What the reader could get wrong |
|---|---|---|
| Written approval is required before booking | Missing | Book before obtaining approval |
| A receipt is needed for the standard claim route | Present | No omission identified |
| The ordinary hotel limit is £120 per night | Present | No omission identified |
| A higher hotel amount requires advance approval | Missing | Assume all amounts above £120 are automatically rejected or accepted |
| Claims are normally submitted within 30 days | Present | No omission identified |
| A stated exceptional late-claim route exists | Missing | Abandon a claim that could be reviewed |
| The rule applies to employees, not contractors | Present | No omission identified |
| The revised policy applies from the stated date | Present | No omission identified |
The summary preserves 5 of 8 conditions, so condition coverage is 5 ÷ 8 × 100 = 62.5%. It omits 3 ÷ 8 × 100 = 37.5% of the conditions in this deliberately small fictional set.
These percentages do not mean the summary is “62.5% accurate”. A correct headline and an omitted approval requirement are not interchangeable units of quality. The ledger identifies what is absent; consequence determines whether the output is usable.
To see why, assume an employee plans two hotel nights at £145 each with advance approval for the higher rate. The difference above the fictional standard is 2 × (£145 − £120) = £50. A summary that omits the approval exception could lead someone to misunderstand the treatment of that £50 even though the £120 figure itself was copied correctly.
Do not turn this into advice about a real reimbursement claim. Apply the method to your actual policy, and refer unresolved interpretation to its owner. The arithmetic demonstrates how a missing relationship can matter more than a correctly repeated number.
Decide whether to repair or reject the summary
My recommendation is to reject a decision summary that omits any known condition capable of reversing its recommendation. This is an editorial acceptance rule. It is stricter than judging whether the general meaning sounds right, and you should adapt it to the consequences of the task.
A reading preview can omit more because its purpose is to point you towards the source. A summary used as a replacement instruction needs stronger coverage. Label the former clearly so it does not circulate as the latter.
Repair the particular claim in plain language, with its condition immediately beside it. Then inspect downstream statements. If an omitted eligibility rule affects three recommendations, fixing the eligibility sentence alone may leave the rest misleading.
If the document's meaning is genuinely ambiguous, preserve that ambiguity and identify the responsible decision-maker. Do not ask the model to resolve a policy dispute simply because it can produce a definite answer. For legal or regulated material, obtain appropriate qualified advice for the relevant jurisdiction when a specific decision requires it.
Check the repaired version as a new document
Compare the edited summary with the ledger again. Confirm that additions have not introduced a new date, changed the actor or combined separate exceptions incorrectly. Copying an exception accurately is insufficient if it now qualifies the wrong sentence.
Use page or section references that a reader can follow. Open them during the check. A reference should lead to supporting text, not just the beginning of a long report where someone else must repeat your search.
Save the corrected version separately from the first draft when maintaining a review record matters. If an earlier version has already been shared, issue a correction to the same audience through the authorised channel. Name the affected instruction rather than quietly replacing a file and assuming everybody will notice.
Audit your next summary in 30 minutes
- Use five minutes to identify the source version, intended reader and decision the summary supports.
- Spend 15 minutes building the exception ledger from the original sections relevant to that decision. Mark unreadable or unavailable evidence explicitly.
- Use ten minutes to compare claims, repair omissions and recheck their dependencies. Preserve source references in the final note.
- Decide whether to use the summary, restrict it to a reading preview or reject it pending clarification.
This timeframe is a working allowance for a short document, not a claim that every policy can be verified in half an hour. Stop and extend the review if you find unresolved conditions, missing appendices or a decision with consequences beyond your competence to assess.
Related guides
Frequently asked questions
Does every qualification in the original need to appear in the summary?
No. The relevant test is whether omission changes the decision, scope or meaning for the stated reader. A summary can compress repeated examples while preserving the actual rule. It should not remove an exception simply because the affected group is small. Define what the summary is for before reviewing coverage, then retain the conditions needed for that purpose. If different readers face different conditions, separate their instructions or point them to the relevant source section. A shorter output is not useful when readers must guess whether the rule applies to them.
Can another AI tool build the exception ledger for me?
It can suggest candidate conditions, but you still need to inspect the original and decide whether the list is complete enough for the task. Otherwise, the second tool may repeat the same omission and create false reassurance. Treat its output as a search aid, not independent proof. If you use another service, confirm permission before sending the document there and consider whether a local manual review would be simpler. A colleague with the relevant subject knowledge may be more useful than another model when the difficulty is interpreting a policy rather than finding text.
What if the summary includes an exception but puts it in the wrong place?
Treat that as a meaning problem, not a formatting detail. A condition placed beneath the wrong rule can change who qualifies, what is permitted or which deadline applies. Return to the source and identify the exact claim the exception modifies. Rewrite them together, using a separate sentence when necessary to remove ambiguity. Then inspect other references to the same rule in the summary. If the source itself is unclear, ask its owner rather than imposing a relationship that the document does not establish. Readability should help preserve meaning, not conceal an uncertain interpretation.
How should I handle a table with conditions in its footnotes?
Read the table and its footnotes as one unit before checking the summary. Record the relevant row, column heading and note together because a number can change meaning when its scope is separated from it. Verify that the application could access those elements, especially when the table is an image. If the extracted text rearranges columns or omits notes, use the visible original for the ledger. Do not repair the meaning by guessing from nearby values. Ask the document owner for an accessible version if the original cannot be read reliably enough for the decision.
Is a summary with full condition coverage safe to use automatically?
No. Coverage of the conditions you identified does not establish that every fact, calculation or interpretation is correct. The ledger addresses one failure mode: decision-changing omissions. You still need to check other material claims and whether the summary answers the right question. An incomplete ledger can also produce a misleading appearance of completeness. Use a level of review proportionate to the action that follows, with a responsible person able to explain it. For consequential decisions, do not turn a passed checklist into permission for unattended action without separately evaluating that workflow.
What if I only have the summary and cannot access the original?
Treat important conditions as unverified and obtain the original before relying on the summary for a consequential decision. Ask for the document version, relevant sections and any appendices, rather than requesting another paraphrase. If access is restricted, ask an authorised person to confirm the specific condition you need. You may still use the summary to formulate questions or decide what information is missing. Do not label it checked merely because its wording is clear or several people repeat it. When the source cannot be obtained, the useful result is identifying that limitation and avoiding an unsupported decision.
Sources and verification
- OpenAI: File Uploads FAQ, checked 9 September 2026 for the distinction between document acceptance, text retrieval and account-dependent visual handling.
- NIST: Generative AI Profile, section 2.2, consulted for documented risks of incorrect and input-divergent output. No product omission rate is asserted.
- The exception ledger, fictional policy and arithmetic are editorial examples, not a benchmark, technical standard or real reimbursement guidance.
This article is practical guidance. Apply it in proportion to your tools, evidence, risks, and responsibilities.
