Your system is easier to discuss when everyone can see which parts connect. OGAD (Off Grid AI Desktop) can turn a written architecture description into a diagram with a local model. Keep the system details on your computer, inspect the rendered result, and correct the connections before sharing it.
| Download OGAD for Mac or Windows | 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.
Use it for a design discussion, an onboarding note, or a proposal. The diagram represents the information you provide. It does not automatically discover a deployed system or prove that the design is secure.
What information should you give the model?
List the components, the direction of each connection, and what moves across it. State any grouping you want, such as browser, application server, and data store.
For example:
A browser sends HTTPS requests to a web API. The API reads and writes an application database. The API adds long-running jobs to a queue. A worker reads jobs from the queue and writes results to object storage. The browser receives results through the API.
Then ask:
Create a Mermaid architecture flowchart from this description. Group the browser separately from backend services. Label arrows with the action. Include only the named components and connections. Return one fenced mermaid code block. List ambiguities separately.
The expected result is a readable first diagram you can review, not a verified inventory.
What can run offline?
OGAD includes a bundled Mermaid renderer. On a supported Mac or Windows computer, a downloaded local text model can generate the diagram code and the app can preview it without a cloud diagram service. This is a free core workflow.
Finish app and model downloads first. Keep the output self-contained, with no remote images or assets. The local artifact runtime supplies the built-in diagram renderer.
Getting started
- Select a downloaded local model in Models > Text.
- Start a chat, or a project chat if you want related diagrams grouped together.
- Send your component description and diagram request.
- Open the artifact card or the reply menu’s Open canvas action.
- Review Preview, then inspect Code when you need the exact labels and connections.
Ask for one correction at a time. For example, “The worker writes to object storage, not the database. Change only that connection and return the full diagram.”
How do you check the architecture?
Walk through a real request from start to finish. Verify that each arrow points in the correct direction and that the label describes the real interaction.
| Check | Question |
|---|---|
| Components | Did the model add a service that you did not name? |
| Connections | Does each arrow correspond to an actual interaction? |
| Boundaries | Are client and server responsibilities grouped correctly? |
| Data | Are the labels clear about what is sent or stored? |
| Uncertainty | Are proposed components distinguished from existing ones? |
A diagram can look organized while omitting authentication, retries, or failure handling. Include those details explicitly when they are relevant, and verify them against the implementation or design record.
Compare an existing design with a proposed change
A useful diagram can help explain why a change matters. Keep the first diagram as the current system, then ask for a separate proposed version rather than allowing the model to blur both into one picture.
For example:
Keep the current diagram unchanged. Create a second Mermaid diagram for this proposal: the API sends the long-running request to a queue, and a worker processes it. Label this diagram Proposed. Do not add other services. List any information the brief does not supply.
Supply that proposal only if it matches the change you intend to discuss. The model does not know whether a queue is appropriate for your actual system from a short description alone.
Then compare one request path in both diagrams. What does the client wait for? Which component stores the result? Which arrow represents the background work? If those questions have no stated answer, record them as open design questions instead of letting a neat diagram settle them.
Give each audience the detail it needs
A high-level diagram can explain the major components to someone joining the project. A closer view can help engineers discuss one interaction. Keep the component names consistent between them so the simplified picture does not appear to describe a different system.
Ask for fewer details by naming what can be omitted: “Keep the client, API, queue, worker, and storage. Leave deployment replicas out of this view.” Check that the simplified diagram still preserves the direction of the data flow.
For a proposal review, keep a short note beside the diagram stating what is existing, what is proposed, and what is not yet verified. That gives readers enough context to discuss the change without interpreting every drawn component as deployed infrastructure.
The AI helps turn a written design into a visible one. Your source description and review still determine whether that picture matches the system.
How do you reuse the result?
Use Download to save the preview as an HTML document. If a documentation tool needs Mermaid text, copy the source from Code. The download is not an automatic PNG or SVG export.
For different audiences, ask for a simplified version while keeping the original. A product discussion may need only the major services; an engineering review may need protocols and failure paths. Check that simplification does not change the meaning.
Download OGAD, describe one request path, and compare the generated diagram with the system you actually run.