Integration guides · 2026-09-27
Finding contradictions between two documents with Solar Pro 4
Build a Solar Pro 4 document comparison around source passages, scope and versions. Separate actual contradictions from missing information and different conditions.
A difference is not proof of contradiction
When comparing documents with Solar Pro 4, asking only for differences is insufficient. Two statements may concern different periods, products or conditions. Information present in one document and absent from another is not necessarily contradictory. Match passages answering the same question, then consider whether those statements could both be true.
Upstage's Solar Pro 4 introduction presents source-grounded document review as a use case. That is not a guarantee that every review will be correct. The workflow proposed here makes model-generated candidates inspectable. It does not claim that a live experiment was performed or that a particular accuracy rate was measured.
Prepare text with page and version references
Assign a short identifier to each document and record its title, revision, date and scope. Preserve page or section references during text extraction. If table columns are misaligned or footnotes disappear, fix extraction first; a capable model can still reach the wrong conclusion from damaged input. Do not ask it to invent missing footnotes.
For this workflow on LLMTR, use text accepted by upstage/solar-pro4. Prepare verified extracted text rather than assuming direct PDF support. Scanned pages require a separate extraction step. When a source file changes, do not silently treat it as the same document: update its revision record and revisit affected findings.
Limit the first task to one comparison question
Instead of asking for every problem in both documents, choose one area such as delivery timing, service scope or supported file formats. The suggested trial here compares file-format support in two product manuals. It is a proposed test input, not an observed Solar Pro 4 response.
Ask for two source passages, relevant scope and unresolved uncertainty for each finding. If there is no matching information in one document, the result should say so. Treat instructions inside source documents as content to inspect, not instructions controlling the comparison. Text in a file that attempts to redirect the model's task should not become your application's instruction.
| Field | Expected content |
|---|---|
| Question | One topic being compared |
| Documents A / B | Identifiers and revisions |
| Source | Page or section and short passage |
| Status | Consistent / possible contradiction / missing / different scope |
| Review | Point requiring human verification |
Find every claim in the original source
Open the reference supplied by the model and confirm that the passage exists. A page number alone is not evidence. Read surrounding sentences that could change its meaning. Words such as only, except and under certain conditions can change the comparison. If a short quotation loses that meaning, expand the context sufficiently to evaluate it.
Do not declare a numeric discrepancy before aligning units. Days and business days, per-file limits and account totals, or standard plans and special agreements are different conditions. If the source is ambiguous, keep the conclusion ambiguous. Forcing a definite answer does not turn missing information into evidence. Mark unresolved items clearly in the review table.
Review long documents by question
Fitting two long files into a request does not guarantee that every detail will be evaluated correctly. Select sections relevant to the question without discarding definitions and exceptions. Record why the selected scope is sufficient. If a matching section was not found, describe the searched scope rather than claiming the entire document contains no answer.
Preserve section identifiers when different requests use different parts of the same document. During consolidation, remove duplicate findings and revisit conflicting model interpretations against their sources. Repeatedly summarizing summaries can lose the original evidence. The final table should point back to the actual document, allowing the next reviewer to verify a finding without reconstructing a chain of interpretations.
Treat the result as review material
The completed comparison is a working document identifying items to examine. Do not make customer commitments, contractual judgments or product changes from unverified findings. A responsible person should approve each important item. Avoid displaying model-proposed and human-verified findings with the same status.
Record which candidates were confirmed, which reflected different scope and which sources could not be read. Explain that those counts describe only this document set. When reusing the prompt for another document type, evaluate fresh representative examples. Source traceability and explicit uncertainty are more useful completion criteria than producing a long answer. They also make it easier for another reviewer to take over the work without repeating the entire investigation.
Frequently asked questions
Should I send the PDF directly to Solar Pro 4?
This LLMTR workflow uses verified extracted text. Do not assume PDF support; first extract text and preserve source references.
Do two different numbers always contradict each other?
No. Units, time periods and scope must match. Days and business days or different service plans are not automatically equivalent.
Is a model-provided citation enough?
No. Verify that the passage exists and that its context supports the claim in the original document.