Before sending a project update, you want to know whether a client asked for something that never received a clear answer. The request may be in a note, a saved message, or a discussion you have not revisited.

OGAD (Off Grid AI Desktop) can help you compare saved requests with later project records using a local model. Build a focused collection, find candidate gaps, and verify their status before drafting the update. The free core document workflow runs on your computer after setup.

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.

The useful result is a checked list of requests to answer, confirm, or carry forward. A model not finding an answer does not prove the request was ignored, so keep that uncertainty visible until you review the sources.

What counts as an unresolved client request?

A request remains open when the available records do not establish a completed response or decision. It may have been acknowledged, partly answered, deferred, or answered in a place you have not included.

Suppose a client asks whether a booking form can support returning customers. A later note says the team will investigate it, but the weekly update never states the result. That is a candidate gap worth checking before the next message.

Use clear statuses:

Status	Meaning for the review
Answered	A source contains a clear response
Acknowledged	The request was seen, but no answer is established
Partly answered	A specific detail remains unresolved
Deferred	The record explicitly postpones the answer
No answer found	The current source set may be incomplete

Do not treat a person being mentioned beside a request as proof that they accepted responsibility.

Which sources should you include?

Collect the requests and later material that might answer them. Use the current project brief, checked meeting notes, saved relevant messages, and approved decision records. Keep dates and source labels clear.

This is a saved-document workflow. It does not automatically read every client inbox or message service. Copy or export only the material you want to review, using your normal access and handling process.

If you already use Mac Pro capture, retained Search, Day, or Replay context can help you locate a request you remember seeing. Capture must have been enabled beforehand, and sampled history is incomplete. Check the original source before adding a request to your final list.

You can use the core workflow without Pro by supplying your own checked files.

How do you set up the review project?

Install OGAD, download a local text model, and complete local indexing setup while connected. Free core Projects are available on supported Mac and Windows computers, with Linux beta packages in 0.0.54-beta.108.

1. Select a downloaded model in Models > Text.
2. Open Projects > New project, name the client engagement, and press Enter.
3. Open Knowledge & settings > Knowledge base > Add files.
4. Add the checked source files and wait for indexing.
5. If Include captured memory is available, turn it off and save to limit this review to the project sources.
6. Open Chats > New chat inside the project.

Use readable TXT, Markdown, DOCX, or text PDFs. Scanned messages or notes need checked text first. The project controls show the source list and retrieval switches.

How do you find candidate gaps?

Ask for the request, any later response, and the evidence for the status. Keep the first output as a review table rather than a client-facing message.

Find client requests in these project records. For each candidate, show the request, source date, any later response, and one status: answered, acknowledged, partly answered, deferred, or no answer found. Cite the supporting source. Do not infer completion from an acknowledgement or invent a deadline.

Review the proposed open items. Search for alternative wording and check the actual deliverable when the answer may have been implemented rather than written as a reply.

For the returning-customer example, the implementation note may call it “existing customer flow.” A literal term difference can hide the connection until you inspect both records.

How do you avoid following up on something already resolved?

Check later sources and the current project state before writing the update. A request can be answered in a meeting, in a revised brief, or through a delivered file.

Ask a focused follow-up:

Find later evidence related to the existing-customer flow. Distinguish a proposed approach, a confirmed decision, and completed implementation. Show dates and sources rather than merging them into one status.

Project search retrieves selected passages within a limited context. It cannot prove that no answer exists anywhere. For an important request, inspect the relevant records directly and consult the person who owns the work if needed.

Keep a manual checked list as the status record. The generated answer is a way to review evidence, not an automatic project-management truth source.

How do you turn the checked list into an update?

Write the response the client needs now. Some items need an answer, others need a decision from the client, and some need a clear statement that work is still underway.

Use:

Draft a project-update section from this checked request list. For answered items, state the answer briefly. For open items, state what is missing and the next agreed action. Do not promise dates or completion that my notes do not support. Keep the tone direct and helpful.

For the example, the update might explain which returning-customer option is under review and what decision is needed before testing. It should not imply that the feature is ready merely because the team discussed it.

Review the draft before sending it through your normal channel. OGAD generating text does not send a message or assign work to another person.

How can you make the next review easier?

After sending the update, save a dated note with the answer or agreed next action. Keep the request linked to that response in your own project records.

Use consistent names for the same feature or decision, while preserving the client’s wording where it matters. Add a short glossary if the project uses several terms for the same thing.

When a document becomes outdated, disable it for retrieval if it should no longer guide current answers. Prior project chats can still contain older discussion, so keep the latest approved source explicit.

Review problem	Next action
Acknowledged means “done” in the draft	Restore the actual status
A later answer is missed	Search related terms and inspect recent records
The model invents an owner	Leave ownership unclear until confirmed
The source set is incomplete	State what was reviewed and add missing records
An old request returns repeatedly	Save the checked resolution with its date

Check the next update before you send it

Download OGAD and review one client’s recent requests against later notes. Finish with a short checked list and an update that makes the remaining work clear.

Keep the model local for processing after setup. Accessing message services and sending the update use their own connections. The useful result is fewer unresolved questions hidden behind a general status report.