Joining a project halfway through can mean reading a brief, several status reports, and notes that disagree. OGAD (Off Grid AI Desktop) can help you turn that material into a useful starting map. With a local model, you can ask questions about project documents on your computer without uploading them to a cloud AI service. The goal is to understand the current work and know what to ask next.
| 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.
Start with the questions you need answered
You do not need to memorise the whole archive on the first day. You need the project’s purpose, present state, key decisions, and next commitments.
Suppose you join a small agency’s website project. The original brief asks for a complete rebuild, but a recent status note mentions a smaller first release. Before taking on a task, you need to find out which scope is current and what caused the change.
Use local AI to build a map of the evidence. Treat answers as a route into the documents, not a substitute for speaking with the project owner.
Select a first source pack
Start with a few documents that describe the current work:
| Source | What it helps establish |
|---|---|
| Approved brief | Purpose, scope, and intended outcome |
| Latest status report | Current progress and open issues |
| Decision notes | Changes and reasons |
| Delivery plan | Dates and dependencies |
| Handover note | Immediate responsibilities and contacts |
Check the dates and approval status. Name files clearly before importing them. If the archive contains several old briefs, keep them out of the first pass unless you need to trace a change.
Ask the project owner which document is authoritative when sources disagree. A newer file can still be an unapproved draft.
Set up a local project in OGAD
Download the desktop app and a local text model that fits your machine. Complete model and local search setup while connected, then test a small question. The workflow uses core Projects and document chat. No background recording is necessary.
- Select the local model under Models > Text.
- Open Projects > New project, enter a name, and press Enter.
- Open Knowledge & settings > Knowledge base > Add files.
- Add readable PDF, DOCX, TXT, or Markdown sources and wait for indexing.
- Keep the current source files enabled for retrieval.
- If available, disable Include captured memory for this first source-only pass and save.
- Start Chats > New chat inside the project.
Scanned PDFs need a checked text version. The desktop extractor reads PDF text and DOCX text; it does not guarantee that diagrams or image-only pages are understood.
Ask for a project map, not a generic summary
Try this first request:
Explain this project to someone joining today. Use headings for purpose, current scope, present status, recent decisions, next commitments, and unknowns. Name the source file for each important point. Distinguish approved decisions from suggestions. If the sources disagree, show the disagreement rather than choosing a version.
Check the result against the source pack. In the website example, look for the difference between the original rebuild and the smaller first release. If the answer mentions only the old brief, ask specifically about the latest status note and decision record.
A useful first answer should help you choose the next document to read. It does not need to cover every task in the archive.
Build a short list of project facts
Create a working note with three labels: confirmed, needs confirmation, and historical. Use confirmed only after you check the source and its status.
For example:
- Confirmed: the approved first release covers the public information pages.
- Needs confirmation: the date for importing old content has no named owner.
- Historical: the original brief included a feature that was later deferred.
These are fictional examples of labels, not conclusions the model can safely assign without your review. Ask the owner about uncertain points before acting on them.
This simple separation prevents old requirements from quietly becoming current work.
Trace one important decision
Choose a change that affects your role:
Find the documented reason for reducing the first-release scope. List the source passages, the dates they state, and any unresolved question. Do not infer a reason from the final outcome alone.
A note saying “release scope reduced” does not establish why. If there is no explanation, record that gap and ask someone who attended the discussion.
For a long archive, add sources in small groups. Retrieval supplies selected passages within a context limit. It may not include every relevant meeting note in one answer. Keep a list of which source sets you reviewed.
Turn your map into questions for the team
Once you have checked the project map, ask:
Based on these reviewed notes, draft five questions for my first project catch-up. Focus on decisions I need before starting work. Do not ask questions already answered by the confirmed notes. State why each remaining answer matters.
Useful questions are specific: “Who approves the content import?” is easier to answer than “How does this project work?” Keep the list short enough for a real conversation.
After the catch-up, write down confirmed answers in your own notes and add them as a dated source if useful. Do not leave important corrections only in an informal chat with the model.
Learn the language of the project
Ask for unfamiliar terms as you encounter them. Request the exact source context and a tentative meaning, rather than a confident general definition.
An acronym might refer to a team, a milestone, or an internal product. If the documents do not define it, keep it on the question list. Once a colleague confirms the meaning, add it to your checked project note.
Project instructions can help keep future answers concise and source-focused. They do not guarantee that the model always follows the requested format.
Keep the map current
When a new plan is approved, mark the old one clearly and review which sources remain enabled. The original file can still matter for history, but current-state questions should not accidentally rely on it.
Keep local inference selected if you want this work to stay on the computer. Remote models, external tools, and device sync have their own network behavior.
Download OGAD and start with the latest brief and status note. Ask what changed, check the evidence, and arrive at your next project conversation with a short list of useful questions.