“Looks good” is not always approval of the final export.
OGAD (Off Grid AI Desktop) can help you find approval language in project notes and supplied documents, then show the sources behind the result. Use a local model and a Project containing the relevant feedback. Ask for exact wording, version and conditions. The model can organise evidence; it cannot grant approval or turn an ambiguous message into consent.
| 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.
What are you trying to establish?
You need to know what the artist approved, which version they reviewed and whether any conditions remain. A positive comment can be useful feedback without authorising delivery, release or publication.
For a small studio or artist-management team, that distinction matters when several files and conversations are active. One person may be discussing the mix, another the artwork and another the release schedule. The same phrase can refer to different decisions.
Build an evidence list that keeps those objects separate. A source-backed answer should make it easier to find the relevant message and ask a focused follow-up where necessary.
Which information should your source notes preserve?
Use the original wording where you can, alongside the context that makes it meaningful. A copied sentence without its date or reference file can be hard to interpret later.
| Detail | Example of the question it answers |
|---|---|
| Person who spoke | Who gave this feedback? |
| Date | Did it come before or after the latest revision? |
| Item or asset | Was the message about the mix, cover or delivery plan? |
| Version | Which file did the person review? |
| Exact wording | Was this approval, praise, a request or a condition? |
| Related source | Where can you inspect the surrounding discussion? |
If a detail is unknown, record that. Do not repair the source by guessing which version the artist must have meant.
Only add records you are authorised to use. This workflow can use saved written notes and supported documents; it does not require connecting every communication service.
How do you create a useful project?
Use this setup for the release or recording project:
- Open Models > Text. Download and load a compatible local text model.
- Open Projects > New project, enter a clear name and press Enter.
- Open Knowledge & settings > Knowledge base > Add files. Select the supported notes and documents for this project.
- Wait for indexing to finish. Check the Knowledge base list and keep the intended files enabled for retrieval.
- If Include captured memory is available, turn it OFF and select Save. This keeps broader captured work out of this supplied-document workflow.
- Open Chats > New chat within the project and ask the first question.
The captured-memory control appears with Pro. In the core project workflow, that additional source option is not offered.
Start with one asset, such as a single track or cover. If the project contains many unrelated approvals, make the first question narrow enough to retrieve the right material.
The desktop project tool searches the active project’s knowledge and conversations. Broader memory uses a different scope, so check that the intended project is active. Project and memory scope.
Projects is a core workflow. You do not need Pro background capture to analyse the records you deliberately add.
What should you ask the model?
Ask for evidence before a conclusion:
Find statements about approval of the Night Bus mix. For each, quote the relevant wording, name the source and date, identify the version when stated, and list conditions. Separate explicit approval, positive feedback and unresolved requests. Do not infer permission to release the track.
Then review the cited passages. If the answer gives only a summary, ask for the exact supporting words and enough surrounding context to interpret them. Retrieval returns a bounded set of relevant material, so this is not an exhaustive approval audit. Check the Knowledge base file list and inspect likely sources directly before concluding that no approval exists.
A useful follow-up is:
Which item still needs a clear answer from the artist? Draft a short question that names the file and the decision required. Do not send it.
That turns uncertainty into a practical next step while leaving the actual decision with the person authorised to make it.
What does a realistic example look like?
Suppose your notes contain these three entries:
- September 10: “The vocal sounds much better in v3.”
- September 12: “Use v4 after the intro is restored.”
- September 14: “The artwork is approved.”
The first entry is positive feedback about a specific aspect. The second contains a condition. The third approves a different asset. None should automatically become “the final track is approved for release.”
Ask for a table separating those statements:
| Source statement | What it supports | What remains open |
|---|---|---|
| Vocal praise for v3 | Positive feedback about the vocal | Approval of the complete mix |
| Use v4 after a change | Conditional choice of a version | Whether the condition was met and confirmed |
| Artwork approved | Approval of the referenced artwork | Which artwork file, if the source does not identify it |
This is an illustrative example. For real work, the original records and your approval process govern the next action.
How do you handle conflicting or later feedback?
Preserve both sources and their dates. A later message may replace an earlier decision, but it may also concern a different asset or describe a new suggestion. Do not rely on chronology alone.
Ask:
Show later statements that could change this decision. Explain which asset and version each refers to. Leave unresolved conflicts visible.
Then inspect the source. If a version cannot be established, ask the artist to confirm the exact file. Include the file name or a clear reference in that follow-up so that the reply becomes more useful evidence.
When the artist confirms, save the response with its context. The next lookup can then use the explicit statement rather than repeating the same uncertainty.
What can go wrong in an AI approval summary?
A model can merge similar messages, lose a condition or treat a polite response as authorisation. Source checking is therefore the central step, not an optional final polish.
| Risk | Review action |
|---|---|
| “After the change” disappears | Keep the condition next to the reported approval |
| Approval of artwork becomes approval of audio | Separate assets in the question and output |
| A version is guessed | Mark the version unknown and ask for confirmation |
| A source is absent | Do not rely on the conclusion |
| Old approval is applied to a new export | Confirm which file the artist reviewed |
The model should help you find the evidence faster. It should not make the delivery decision on your behalf.
Can you keep the lookup local?
Yes, when you use downloaded local models and prepared local documents for the task. Initial downloads and any external communication need their own connectivity. A saved feedback file can be analysed offline; sending a follow-up through email or a community service is a separate action.
Review the data route if you select a remote model or external tool. This article’s workflow does not require those connections, and it does not claim a legal approval audit or automatic rights clearance.
Make the next approval easier to find
After each decision, retain a clear note with the asset, version, wording, date and source. Ask specific questions about that evidence instead of asking the model whether everything is “good to go.”
Try OGAD with one project’s saved feedback. Find one approval, inspect the supporting words and identify the next question that still needs a human answer.