The most impressive moment in many AI design tools is simple: you type a sentence, and the tool gives you an image, a model, or a space that looks almost finished.
But once you move from a demo into a real design workflow, the hard questions appear quickly.
Can this result keep being edited?
Where did the walls, doors, objects, and dimensions come from?
When a designer points out a problem, did the AI repair the structure, or did it only patch the visible output?
When the project is opened again, how does the agent know what was design intent, what was a temporary experiment, what came from a source drawing, and what was only an assumption?
This is why I think AI design tools should not optimize only for "it looks generated." They need an editable, verifiable, repairable, replayable source of truth.
By "source of truth," I do not mean that AI should decide what good design is. I mean a structured working fact layer where intent, evidence, spaces, dimensions, components, rules, assumptions, and execution results have a place to live, can be checked, and can be repaired when they are wrong.
Output Alone Is Not Enough
If AI only generates an image, the result is easy to understand visually, but it is a weak long-term working base.
An image can express style, mood, and direction. It is much less reliable at carrying:
- wall thickness
- door and window openings
- space boundaries
- component dimensions
- clearance rules
- drawing evidence
- design assumptions
- change history
The same problem appears when AI only manipulates a SketchUp scene. The SketchUp scene matters, but it does not automatically tell the agent why an object is there, which dimension came from a designer instruction, which one came from an imported drawing, and which change was only a temporary exploration.
Chat history is not enough either. Conversation is good for expressing intent and discussing judgment, but it is a poor long-term structured state for a design project.
A reliable AI design tool therefore cannot have only a final image or a final scene. It needs to know what the current project actually is.
A Source of Truth Makes the Project Continue-able
In SketchUp Agent Harness, design_model.json is the structured working truth for a design project.
It is not an aesthetic judgment. It is not a legal compliance report or a construction document. It is closer to a shared project state between the designer and the agent.
It should record things like:
- how spaces are organized
- what the dimensions and units are
- which components are already in the project
- what semantics, anchors, and clearances those components have
- which design rules are currently active
- which conclusions came from an imported drawing, image, or scan
- which parts are assumptions
- which visual feedback needs to become a structured change
With that layer, an agent can do important work:
- compare versions
- check whether the structure is reasonable
- repair a model using source evidence
- replay the structure into SketchUp
- turn visual feedback into precise model changes
That is the value of a source of truth. It does not make the output more spectacular. It makes the project understandable, checkable, and repairable.
The SketchUp Scene Is Not the Source of Truth
This can be misunderstood.
The SketchUp scene is important. Designers need to see, inspect, adjust, and often deliver work through SketchUp.
But for an agent, the SketchUp scene is better understood as a live execution result. It is the result of execution, not the whole project truth.
There are three reasons.
First, a software scene contains a lot of implicit state. It is hard for an agent to know the evidence, assumption, or design intent behind every object.
Second, a scene can mix several rounds of experiments. Without structured records, it is hard to tell what should remain and what was only leftover exploration.
Third, repair can easily become patching the current picture. That may improve the short-term appearance while making the long-term project harder to trace.
A stronger loop looks like this:
design intent
-> structured truth
-> SketchUp execution
-> visual review
-> structured repair
In other words, the SketchUp scene and screenshots should feed back into structured truth.
Visual Feedback Must Return to Structure
Visual review matters.
A top view can expose wall misalignment, missing openings, reversed orientation, or an exterior void that was mistaken for a room. A render can expose material, lighting, scale, or style problems.
But visual feedback should not stop at "this image looks wrong."
If a designer says:
"This wall is too thick."
Or:
"This opening should not be sealed."
Or:
"This area is not a room. It is an exterior void."
A good agent should not only tweak the current view. It should turn that feedback into structured actions:
- update wall thickness
- correct space boundaries
- update opening evidence
- add a validation failure
- record uncertainty in the source interpretation
- create a replayable model diff
The next time the project is opened, the agent should not merely remember that the user disliked an image. It should know how the project truth changed.
Floor Plan Import Especially Needs a Source of Truth
Floor plan import is a useful example.
If a user gives AI a DWG, DXF, PDF, image, scan, or photo, the weakest workflow is to generate a model that looks plausible and then treat it as fact.
A more reliable workflow should:
- Register the source.
- Preserve source evidence.
- Interpret scale, orientation, boundaries, rooms, walls, and openings.
- Generate a first editable working model.
- Execute or preview it in SketchUp.
- Use a top view, screenshot, or validator to find problems.
- Write repairs back into structured truth.
The first import result should not be treated as a verified survey. It is working truth.
That distinction matters.
AI does not need to be perfect on the first pass. It needs to admit what came from evidence, what was inferred, what is uncertain, and let the designer repair errors in natural language.
What This Means for Designers
If an AI design tool has a structured source of truth, the designer's role becomes clearer.
Designers do not need to manually execute every low-level modeling step, and they should not need to restate the same project context in chat again and again.
They should spend more attention on higher-value work:
- judging whether a space makes sense
- confirming design intent
- choosing style and material direction
- managing constraints and tradeoffs
- reviewing visual output
- deciding which feedback should enter project truth
AI should not turn designers into drafting operators who happen to use natural language. A better direction is to let designers become directors and reviewers of the workflow.
What This Means for AI Products
For AI products, a source of truth changes the architecture.
If a product only optimizes for output, it can focus on prompts, image generation, and one-off results.
If it wants to enter real workflows, it has to handle more structure:
- project directories
- structured models
- source evidence
- runtime skills
- design rules
- component metadata
- software bridges
- validators
- versioning and replay
- visual review loops
SketchUp Agent Harness is interesting not because it is already a mature platform, but because it exposes this problem clearly.
Claude and Codex are only entry points. The more important layer is the combination of an MCP server, a SketchUp Ruby bridge, runtime skills, protocol documents, and design_model.json.
That middle layer decides whether the agent is generating a result or maintaining a project.
A Source of Truth Is Not a Universal Answer
The boundary also needs to be clear.
design_model.json is not aesthetic judgment.
It cannot decide whether a space is beautiful.
It is not a construction compliance report and should not be treated as legal, code, or engineering review.
It is a structured working fact layer. It carries current project state, sources, assumptions, rules, and repairable structure.
The real design judgment still belongs to the designer.
This is why "source of truth" should not mean "the only correct answer." In this context, it means "the single traceable working state."
Conclusion
When I evaluate whether an AI design tool has really entered a workflow, I look for answers to a few questions:
- Where is the current model's structured state?
- What evidence supports each important conclusion?
- Do the visual output and structured model agree?
- What concrete change does designer feedback become?
- Can the project be checked, repaired, and replayed?
If those questions have no answer, the AI is still mostly an output engine.
If those questions have answers, the AI is starting to become a real design workflow tool.
That is why AI design tools need a source of truth.
Originally published on my personal site:
https://marlinbian-site.pages.dev/writing/why-ai-design-tools-need-a-source-of-truth/
More links: GitHub · YouTube · LinkedIn · Bluesky · Mastodon · Discord
Top comments (0)