ThoughtGlass · Independent exploration · 2026

An AI reading should be
open to correction.

ThoughtGlass explores what happens when a person can inspect an interpretation, change its relationships, and keep the earlier reading visible.

My responsibility
Product direction, interaction requirements, and review
Collaboration
AI-assisted design and implementation
What you can inspect
A supplied engineering example in a worked demo

01 · The problem

“Engineering may not trust UX.”
What if that’s the wrong relationship?

In the supplied example, the system reads an engineering concern as a lack of confidence in UX. The correction moves the issue to system stability: engineering could support the concept if a component contract constrained designers too, especially under delivery pressure.

The design problem is how to make that change inspectable. A revised sentence alone would leave the reader to work out what the system changed and what it carried forward.

02 · My contribution

I made traceability a requirement.

I directed ThoughtGlass’s development and required error states to remain distinguishable. I challenged its single-domain scope and asked for motion to explain the shapes and connections of thought.

During use, I reported that the experience froze after one or two corrections and asked for a UX audit. That report establishes a design-review action; the record cited here does not establish that the historical defect was fixed.

These are attributable direction and review decisions. The working interface was developed with AI assistance; this case does not claim sole implementation authorship.

One correction, three visible states

Actual demo captures · September 8, 2026

The sequence follows “Not quite,” uses the correction supplied by the demo, previews it, and applies “Show me the change.” Open any image to inspect the original capture.

Initial state: Engineering may not trust UX. The system labels this a hypothesis awaiting the person’s reading.
01 · Proposed

Show the reading as provisional.

The interface marks the system hypothesis as awaiting a person’s reading and offers “Accurate enough” or “Not quite.”

Preview lists five operations: remove, add, reconnect, constrain, and qualify, with Edit and Show me the change controls.
02 · Preview

Make the proposed changes explicit.

Remove the earlier relationship; add system stability and a component contract; reconnect, constrain, and qualify. The person can still edit.

Corrected state: a new graph connects system stability and a component contract. The rejected graph remains as history, and a new question appears.
03 · Corrected

Keep the rejected reading in view.

The graph changes, the earlier interpretation stays visible as history, and the sequence opens a question about the larger framework.

03 · The design judgment

Correction changes what the system is allowed to carry forward.

My requirement for traceable states gives the interaction a concrete test: can a person distinguish the system’s proposal from their correction, and see the relationship between them?

The sequence makes that distinction visible through labels, a structural preview, and retained history. The next question can then refer to the revised structure without making the rejected reading disappear.

Disagreement is not noise to remove. Designed properly, it is the next state of the system.

04 · Evidence and open questions

What this example demonstrates

Observed in the demo

The supplied correction produces a preview, a graph redraw, a retained historical reading, and a new question. These screenshots show that bounded sequence.

Still to establish

Interpretation of arbitrary corrections, reliable repeated use, durable history, and benefit to other people. A worked sequence does not establish those capabilities or outcomes.

Separate versions: the blank-start tablet draft and gesture explorations are distinct experiments. The contract replay is a guided account of an exchange between Krystel, Claude, and Astra. It is not the engineering demo pictured here.

05 · The next test

Can someone else explain what changed?

The next useful evidence is a person using the sequence without coaching: identifying the original reading, explaining the correction, and distinguishing what they confirmed from what the system still proposes.

That reader test has not been run for this case study.

Try the supplied example

Start a conversation

What are you trying
to make understandable?

I’m interested in product design work where AI, complex systems, and human judgment meet.