The brief says one thing. Your meeting notes seem to say another. Before the team builds the wrong version, you need to know exactly where the difference is.
OGAD (Off Grid AI Desktop) can help you compare readable documents with a local model on your computer. Ask for differences with supporting passages, check each one, and turn unresolved conflicts into questions for the decision owner. The result is a review list you can act on, without treating AI output as an approved scope change.
Download OGAD | Desktop releases
What would you like to do with Off Grid AI?
Have a feature or use case you would like us to support? Tell us what you want to do and which device you use.
Write to support@offgridmobileai.co, join our Slack community, or talk to us on Reddit.
This helps a small delivery team when decisions move faster than formal documents. A useful comparison can show whether a meeting clarified the brief, proposed a change, or introduced a real contradiction.
What is a contradiction rather than a missing detail?
A contradiction occurs when two statements cannot both apply under the same conditions. A missing detail is a gap. A proposed change is an option that may not yet be approved. Keep those categories separate so the review does not exaggerate differences.
Suppose a project brief says the booking form must collect a phone number. A meeting note says “Let customers book with email only.” That may be a contradiction if both refer to the same booking route.
But if the note concerns returning customers only, it may be an exception. You need the surrounding context before changing the form.
| Difference type | What to establish |
|---|---|
| Direct conflict | Two incompatible requirements for the same case |
| Exception | A different rule for a named condition |
| Missing detail | One source leaves something unspecified |
| Proposed change | A suggestion without clear approval |
| Superseded decision | A confirmed later decision replaces an earlier one |
A table with these categories is more useful than a general warning that the documents are inconsistent.
Which versions should you compare?
Choose the brief currently used for delivery and the notes from the relevant meeting. Record their dates and approval status. A file saved yesterday is not necessarily more authoritative than a brief approved last month.
Use readable TXT, Markdown, DOCX, or text PDFs. Keep copies of the original files before editing. If a PDF contains only scanned images, prepare a checked text version first.
For a first review, select one topic: booking fields, approval rules, delivery dates, or access requirements. A focused comparison makes it easier to inspect each source passage.
This procedure uses the free core app on supported Mac and Windows computers. Release 0.0.54-beta.108 also has Linux beta packages. Download the app and local text model before disconnecting from the internet.
How do you compare two short documents?
Attach both files to a chat and ask for a bounded comparison. Label each source clearly so the model can distinguish the approved brief from meeting notes. Read the extracted text before relying on the answer.
- In Models > Text, select a downloaded local model that fits your computer.
- Open a new chat and select + > Attach files.
- Attach the brief and the meeting notes.
- Wait for processing and open each attachment's text preview.
- Check that the relevant sections are present and readable.
The file-processing path extracts text for chat. It does not preserve every visual layout detail, comment, or meaning conveyed by a document's formatting.
Ask:
Compare the booking requirements in these two files. For each possible difference, quote a short passage from each source and classify it as direct conflict, exception, missing detail, proposed change, or unclear. Explain the condition under which the statements would conflict. Do not decide which source is authoritative.
How do you check the proposed conflicts?
Read both quoted passages and their surrounding sections. Confirm that they refer to the same user, stage, and condition. Small scope differences can make apparently conflicting statements compatible.
For the phone-number example, check whether one source describes new customers and the other returning customers. Look for words such as “optional,” “unless,” “initially,” and “after approval.”
Keep a review table outside the generated answer:
- Topic under review.
- Brief passage.
- Meeting-note passage.
- Your classification after checking.
- Question or action needed.
Do not copy every suggested conflict into a client message. Remove false positives first. If the model quotes wording that is not in the source, discard that item and inspect the relevant section directly.
What if the files are too long?
Compare relevant sections rather than asking one model request to cover the entire archive. The model context must fit the documents, instructions, conversation, and answer. A complete attachment preview does not mean the whole text fits usefully in one prompt.
You can also create a project for repeated source lookup. Open Projects > New project, then Knowledge & settings > Knowledge base > Add files. Wait for indexing and open Chats > New chat inside that project.
Project search retrieves selected relevant passages. Use it to find the sections you need, then review those sections directly. It is not an exhaustive document-difference engine and does not prove the rest of the files agree.
For a thorough review, make a topic checklist from the brief and work through each topic. Mark what you reviewed so missing retrieval results do not become an assumed pass.
How do you ask the client to resolve a conflict?
State both interpretations and ask which should govern the work. Keep the message neutral and specific. Include the relevant source dates so the recipient can recognise the context.
For example:
The approved brief requires a phone number for booking. The workshop notes describe email-only booking. Should email-only booking apply to all customers or only returning customers? We need this to finish the required-field rules.
Ask the local model to draft from your checked table:
Write a short clarification request for these confirmed differences. Name both interpretations, ask one decision per item, and state what work depends on the answer. Do not claim a change is approved.
Review the draft and send it through your existing process. The app generating a question does not send it or obtain approval.
How do you keep the answer from becoming another conflict?
When the decision owner responds, update the approved brief or decision record. Add the date, the chosen rule, and the condition it applies to. Tell the delivery team where the current requirement lives.
If you use a project knowledge base, disable outdated document versions when they should no longer guide retrieval. Prior chats can still contain earlier discussion, so keep the current approved record explicit and check sources in later answers.
| Review failure | Better next step |
|---|---|
| The model chooses a winner automatically | Ask for evidence and leave authority to the owner |
| Missing detail is called a contradiction | Check whether both statements can be true |
| A newer draft overrides an approved brief | Verify approval status, not just file date |
| A long comparison omits a section | Use a topic checklist and smaller source sections |
Check one requirement before changing it
Download OGAD and compare the current brief with one set of notes. Finish with a checked difference and a clear question, or evidence that the two statements can both apply.
Keep the model local for processing on your computer after setup. Remote model choices and sharing files are separate data paths. The goal is a better decision record, not an automatic decision about the project's scope.
Top comments (0)