Lucid: turn rough notes into a diagram you can check

What the documentation establishes

Lucid uses an external dictation tool or typed text; it does not transcribe audio itself. The language model runs locally through LM Studio. Source ↗

Its diagram builder separates parts, connections and numbered edits. PDF, Markdown and native history exports serve different handoff needs. Source ↗

The install guide documents qwen/qwen3.8-27b as tested and first-use downloads for PDF typesetting. Other model choices are not established by that test. Source ↗

The Mac control reference lists Command-4 for diagrams, Command-2 for commands and Command-3 for direct editing. Native .lucid export includes history. Source ↗

The walkthrough below is an original worked exercise. We have not independently tested this product’s performance.

1. Prove the input path before drawing

Use an empty document and fictional information. Start with typed text even if your eventual goal is hands-free notes. That isolates text understanding from speech recognition: if the typed exercise works and dictated text does not, you have a narrower problem to investigate. Keep the source specification in a separate note so you can compare it with the output.

In LM Studio, start the local server and load the documented model if your hardware supports it. In Lucid, use the status pill to check again or load the model. The author used a Mac with 48 GB of memory; this is not evidence that the same configuration will fit a small laptop. Do not silently substitute a different model and assume identical behaviour.

2. Make a tiny specification with a clear finish line

Our fictional process has five components. An intake form passes an invoice to a checker. An incomplete invoice returns to intake. A complete invoice goes to a reviewer. The reviewer either returns it to intake for correction or sends it to a ledger; the ledger records a completion in the archive. This is a diagram of information movement, not a payment system.

Write the expected connections before asking for a drawing. That provides a small answer key which remains independent of the generated layout. There are exactly five nodes and six directed connections. Nothing in the exercise requests a bank connection, an email or an external action.

Fictional invoice review
Nodes: Intake, Checker, Reviewer, Ledger, Archive.
Connections:
Intake -> Checker: submitted
Checker -> Intake: incomplete
Checker -> Reviewer: complete
Reviewer -> Intake: correction requested
Reviewer -> Ledger: approved
Ledger -> Archive: recorded
Do not add services, extra states, or payment actions.

Before generation, read those six lines aloud or point to each with a cursor. The two return paths are intentional. If the tool turns this into a simple left-to-right chain, the image may look cleaner but has lost a requirement.

3. Add parts first, then relationships

On macOS, press Command-4 to open the documented diagram builder. Supply the five names during the parts phase. During connections, add one relationship at a time from the specification. In the editing phase, inspect the numbered items. Finish with done only after the names and arrows match. For other platforms, use the displayed app controls; the checked reference lists Mac shortcuts.

Keep each input short. Do not simultaneously request a new layout, rename a node and alter three arrows. Small changes make the history easier to inspect and let you identify which instruction produced a mistake. Numbered references must use the numbers actually shown in your document; the ordering below is not a promised UI numbering.

Connect Intake to Checker and label the connection submitted.
Then, as a separate instruction:
Connect Checker back to Intake and label it incomplete.

4. Change one requirement and check for leftovers

Now change the fictional policy: the reviewer should be called Approver. This should change one node label while preserving every connection. Choose the node number actually visible in your diagram and request that single edit. Review the source specification alongside the result; a text mention in a heading can become stale even when the node changes. Once the diagram is on the page, use Command mode (Command-2 on macOS) for instructions about it. Use Edit mode (Command-3) if you prefer a direct text correction.

Next ask for a short explanation of the two return paths. It should describe incomplete information and a requested correction as distinct cases. It should not invent a rejection archive or automated payout. The exercise measures consistency across the picture and the prose, not just whether the model accepts an instruction.

Rename [the displayed Reviewer node number] to Approver.
Preserve all six directed connections and their labels.

Explain why there are two return paths to Intake.
Use only the diagram and supplied specification.
List any uncertainty; do not add a new process stage.

Inspect history to connect the edit with its instruction. If the result is wrong, undo that change, clarify the wording and try once more. Record the extra effort. For a small correction, direct editing may be quicker than repeated conversational repair; that is useful evaluation evidence, not a failure of the entire approach.

5. Produce a handoff another person can review

A useful handoff contains the specification, diagram and review note. Export a PDF for someone who only needs to read it. Keep a native export with history when you need to continue editing or explain a change; Markdown includes diagrams as Mermaid blocks. In Settings → PDF look, choose a readable text size and the intended paper size before exporting. Do not assume a PDF is an editable project backup.

Open the exported PDF and inspect a return arrow, a long label and the explanatory paragraph. A correct canvas can still become an awkward page break or tiny text in an export. Ask a colleague to answer one question using only the handoff: what happens when an invoice is incomplete? If the answer requires your verbal explanation, improve the document before expanding the example.

Purpose: explain a fictional invoice review process.
Expected: 5 nodes; 6 directed connections; 2 return paths.
Revision: Reviewer renamed to Approver; connections unchanged.
Checked: [names] [directions] [labels] [explanation] [PDF legibility].
Correction effort: [minutes and number of retries].
Files retained: [specification] [readable export] [editable backup].
Limit: this is documentation; no process has been automated.

6. Locate the failure before changing the model

Record three timings separately: setup, first draft, and verification/correction. Compare the last two with a manually drawn version of the same five-node process. A one-time installation cost matters differently from recurring correction time. Repeat with a second small process before making a broad productivity claim.

This guide checks documentation and supplies an original evaluation exercise. It does not claim that the published example ran successfully, that every export preserves every feature, or that the tool meets an accessibility requirement for every person. Your retained input, output and correction history are the evidence for your own decision.

Guide history

Revisions preserve the original instructions. A source recheck alone does not create a new revision.

Revision 1 · New documented guide with a five-node worked diagram, six-edge answer key, correction exercise, export handoff and troubleshooting; explicitly unexecuted.

Continue learning