You finished the project. The useful lessons are still spread across meeting notes, delivery documents, and an old brief.

OGAD (Off Grid AI Desktop) can help you search those files on your computer and draft a short lessons document from the evidence. Add a focused collection to a project, use a local model to find relevant passages, and check the result before deciding what to change next time.

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.

For a small consultancy or agency, the useful result is a change you can use in the next proposal, kickoff, or review. “Communicate better” is too broad. “Confirm the person who can approve the design before the first review” is something the team can do.

Which files should you use for a project review?

Choose documents that show what you intended, what changed, and what happened. A final report alone may omit the decisions that caused extra work. Start with a small archive whose contents you understand, rather than every file from every engagement.

Suppose your team delivered a new booking website. The launch was successful, but the approval stage took longer than expected. You want to know what should change before the next project.

File	What it can help establish
Original brief	The agreed scope and assumptions
Dated meeting notes	Decisions, changes, and unresolved questions
Change log	Work added or removed during delivery
Final handover	What was delivered and what remained open
Review notes	The team’s interpretation of what worked

Keep facts and opinions visible. A note saying “approval was slow” is an interpretation. Dated requests and responses can help you understand the specific delay. If the archive does not contain those records, leave that part unresolved.

What do you need before starting?

Use OGAD with a downloaded local text model and the resources for local document indexing. Complete installation and initial model setup while connected. Projects and uploaded-document chat are free core features on supported Mac and Windows computers.

Linux packages are also available in release 0.0.54-beta.108, a beta release. This guide uses saved documents and does not depend on Pro activity recording.

Use readable TXT, Markdown, DOCX, or text PDF files. For scanned documents, prepare a checked text version first. Importing a PDF does not guarantee that text in images will be available for search.

Keep the original files. Give copies clear dates and names so you can recognise sources when the model returns an answer.

How do you create the review project?

Create a separate project for the archive and add the selected files to its knowledge base. Wait for indexing before asking questions. The project interface lets you add documents and enable or disable them for retrieval.

1. Select a downloaded local text model in Models > Text.
2. Open Projects > New project, enter a name, and press Enter.
3. Open Knowledge & settings > Knowledge base > Add files.
4. Select the archive files and wait for indexing. Leave their retrieval switches enabled.
5. Open Chats > New chat inside that project.

Start with a question tied to the known difficulty:

Find passages about design approval in these project documents. Show the source filename and date where present. Separate agreed approval steps, changes to those steps, and unresolved questions. Do not assume why a delay happened unless a source explains it.

Open each source you intend to use. The answer should give you leads for a review, not a substitute for the review itself.

How do you turn findings into useful lessons?

For each checked finding, write the situation, the observed consequence, and a proposed change. Ask the model to keep those three parts separate. This prevents a plausible recommendation from appearing to be a documented fact.

For the booking project, suppose the notes show that the client added a second approver after the first design review. The useful lesson could be to confirm all required approvers during kickoff. That lesson comes from the specific sequence, not from a general complaint about client feedback.

Try this prompt:

Using only the checked findings below, draft a lessons table. Include the source event, what the evidence shows, the remaining uncertainty, and one practical change for the next project. Mark proposed changes as recommendations. Do not assign blame or invent causes.

Review whether each proposed change is proportionate. A small approval problem may need one kickoff question, not a new process with five forms.

Keep useful practices too. If a short technical review caught a problem before launch, record when to repeat that review and who should attend. The archive should help you preserve what worked.

Can you find patterns across several projects?

Yes, but first create checked notes for each project. Then compare those notes using the same questions and definitions. A set of summaries makes differences easier to inspect than a large mixed archive with inconsistent document names.

Use a second collection of reviewed lessons and ask:

Compare these project reviews. Which issues appear in more than one review? Name the supporting projects and describe the important differences. Keep a single-project observation separate from a repeated pattern.

Project search retrieves selected passages within a limited context. It does not establish that every document was inspected. Do not treat the number of returned examples as the total number of times an issue occurred.

If you need a reliable count, check each project against the same rule and maintain your own table. Use AI to help locate evidence, then record your decision.

How do you make the lesson change the next project?

Choose one action that belongs in an existing step. Add an approval question to the kickoff checklist, a file-format requirement to the brief, or an acceptance check to the handover template.

For each action, record:

• Where it belongs in the next project.
• Who will use it.
• What evidence would show that it helped.
• When you will review whether to keep it.

This turns the review into a small experiment. It also gives you a reason to return to the lesson after the next delivery.

What if the archive gives conflicting accounts?

Keep both accounts with their dates and sources. Ask whether one describes an earlier plan and the other a later decision. If the difference remains unclear, mark it for the team to resolve.

Problem	Next check
The answer blames a person	Replace it with the documented event and consequence
A finding has no source	Remove it from the evidence list until checked
The lesson is too broad	Ask what specific step should change
A large archive gives thin answers	Review one topic or phase at a time
An old chat influences the answer	Use a new project with only the intended sources; earlier chats in the same project can supply context

Review one completed project

Download OGAD, add a brief and a few dated notes, and investigate one delivery problem. Finish with one checked lesson and one change for the next kickoff.

Local models let you do that analysis on your computer after setup. Remote models, device sync, and later sharing are separate choices. Keep them aligned with how you want the archive handled.