A prompt I keep using when I test scientific image models is short: "Draw the MAPK pathway."
That sentence leaves most of the important decisions unstated. Which branch matters? Which cell type are we talking about? Does an arrow mean activation, transport, or simply "this happens next"? Is the figure explaining a known mechanism or summarizing one experiment?
A model can make those missing decisions on its own. The result may look polished and still be scientifically useless.
The picture is the last step
When I started working on text-to-figure generation, I spent most of my time thinking about rendering. Line quality, spacing, color, export size. Within a week, I was spending more time checking arrows than pixels.
The useful intermediate artifact turned out to be a small figure specification. Mine often starts this simply:
{
"purpose": "Show how MEK inhibition changes downstream ERK signaling",
"entities": ["MEK", "ERK", "transcription factor"],
"relations": [
{ "from": "MEK", "to": "ERK", "kind": "activates" }
],
"evidence": "literature plus this experiment",
"exclude": ["unmeasured branches", "unlisted proteins"]
}
This is not a production schema. It is a quick way to expose decisions before a model hides them under attractive pixels.
If I cannot write the purpose in one sentence, the figure usually has too much work to do. Shrinking the labels will not fix that. I split the figure instead.
Arrows need types
An arrow is one of the easiest shapes to draw and one of the easiest ways to make a false claim.
In a workflow, an arrow may mean sequence. In a pathway, it may mean activation or inhibition. In an equipment diagram, it may mean material flow. Those meanings should not be interchangeable just because they share the same SVG path.
For a developer, the relation deserves its own type:
type Edge = {
from: string
to: string
kind: "activates" | "inhibits" | "transports" | "next-step"
evidence: "measured" | "literature" | "interpretation"
}
The type does two useful things. It lets the renderer choose a visual convention, and it gives the validator something concrete to inspect. A vague "connect these nodes" instruction gives us neither.
I also keep relation meaning out of color whenever possible. Color disappears in grayscale printing, on poor projectors, and for some readers with color-vision differences. Arrowheads, line styles, and labels carry the meaning. Color can help, but it should not be the only carrier.
Evidence and explanation need different treatment
Scientific papers mix several kinds of visuals. A chart presents measurements. A microscopy image records an observation. A mechanism diagram explains how the author thinks pieces fit together.
The trouble starts when a generated illustration borrows the visual authority of measured data.
A detailed receptor model can imply structural precision that was never measured. A realistic anatomical cutaway can look patient-specific even when it is generic. The more convincing the render, the easier it is to miss that distinction.
I now attach a source category to anything that enters a figure:
- measured in the current work
- supported by cited literature
- interpretation or hypothesis
- orientation only
Those categories can change line weight, labels, captions, and citations. They also make review easier. A co-author can disagree with the category without arguing about the entire composition.
For explanatory figures, I often prefer plain line art to a cinematic render. Lower visual detail leaves less room for accidental claims.
My validation loop is deliberately boring
I used to regenerate a figure until one version felt right. That loop rewards appearance. A clean layout can distract me from a wrong connection.
Now I check four things in order:
- Is the topology correct?
- Do the labels match the paper or source material?
- Can I explain what every arrow means?
- Is the figure readable at its final size?
A typo is usually a local edit. A topology error sends the figure back to the specification. There is no point tuning shadows on the wrong graph.
The final-size check catches more problems than I expected. A figure that looks comfortable in a full browser window may collapse inside a two-column paper. I test the exported size, not the editor view.
Where generation fits
Generative tools are useful for mechanism sketches, experimental workflows, equipment concepts, and early graphical-abstract drafts. They reduce the cost of getting from an empty canvas to something a team can discuss.
They are a poor substitute for data-driven charts, original microscopy, diagnostic images, or exact chemical structures. Those visuals should come from the underlying data or specialist software. A generated image may explain evidence, but it should not impersonate it.
I eventually built parts of this workflow into Scientific Figure Generator. It can produce line art, flat illustrations, and 3D-style drafts from text. I still treat every result as a draft, including the ones that look finished.
The product question I keep coming back to is how much structure to expose. Too little invites invented relationships. Too much turns a quick visual task into a long form with dozens of fields. I do not think that tradeoff has a universal answer.
For now, my rule is simple: before a generated diagram reaches a paper or presentation, every relationship in it needs a source. If I cannot find one, the figure is not ready.
How are you handling semantic validation when AI generates diagrams in your own tools?
Disclosure: I used an AI writing assistant to help edit the English and tighten this draft. The examples, workflow, and product decisions come from my work building scientific-visualization tools.
Top comments (0)