Selected work / Case study 01
Continuity
with consent.
Designing AI memory people can permit, inspect and correct: permission before retrieval, evidence on request, and an honest account of what's proven.
- My role
- Product direction, interaction design, requirements, acceptance testing
- Timeline
- January–October 2026
- Built with
- AI coding agents directed by me, with an independent AI reviewer
- Status
- Installed and in daily use by me; no external users yet
AI kept saying
it remembered.
Every new chat started from zero. And when an assistant did "remember," it sometimes invented details, claimed work was saved when it wasn't, or quietly replaced my original words with its own summary.
For long-running work, that's worse than forgetting. Once you've caught a system inventing one memory, you can no longer tell which of the others to trust.
False memory is a problem of trust.
So before designing any feature, I set three rules the whole system had to keep:
Original words are evidence
Summaries and decisions link back to what was actually said. A summary never replaces its source.
Approval is explicit
Nothing becomes approved on its own. Discussing something is not permission to act on it.
Done means I can open it
A receipt or a claim is not proof. The saved record has to open, and its content has to check out.
I design the behavior.
AI writes the code.
I'm the only designer and tester. I set the goals, requirements and interaction direction, compared models, and decided what met acceptance. AI coding agents wrote the code and helped with research and documentation, and an independent AI reviewer had to pass every release before it was installed.
- 1
Define
Name the failure people work around and what it costs them.
- 2
Specify
Write the behavior, the boundaries and how failure should look.
- 3
Direct
Guide AI coding agents through the build.
- 4
Review
An independent reviewer must pass the release.
- 5
Accept
Only what I can open, use and verify myself.
One home for memory decisions.
Automatic memory only works if people can see and steer it. The design question was where those choices live, and how specific they need to be.
123- 1
Separate permissions
Searching on this Mac and sending to a cloud model are different grants. Allowing one never implies the other.
- 2
Distinct choices, not one switch
Turn memory off, keep a single chat out, or skip just the next message. Each says exactly what it does.
- 3
Reachable, not repeated
The controls live in one place instead of under every message, so the conversation stays a conversation.
Conversation first.
Evidence on request.
At rest, an answer that used memory carries one quiet line: "Memory · 1 source." Open it and you see the exact excerpt, who said it and when, and how the assistant used it.
At rest
1On request
2Interface capture with synthetic records and scripted replies
What the interface says about itself
"StephOS checked only that each label refers to an excerpt that was supplied; it did not verify the judgement."
I wanted the interface to state its own limit. Honesty is a design surface, not a footnote.
Retrieval only with permission.
Every answer that draws on memory passes the same path, and each step is a boundary the person can rely on.
- 1
Permitted collections
Only what the person allowed, for this use, can be searched.
- 2
Sources keep their identity
Each excerpt stays tied to the chat, note or saved work it came from.
- 3
History stays grouped
A replacement never erases what it replaced.
- 4
Checked at send time
Permission and source are rechecked just before anything leaves the device.
- 5
Answer, not approval
Reviewing and saving stay separate, deliberate acts.
The trade-off
Automatic recall removes repeated manual choices, but adds consent, relevance and index upkeep. I chose to carry that complexity in the system rather than hand it to the person.
Right answers.
Uninvited memory.
I tested recall on a set of 24 synthetic questions across two versions. The facts came back right every time. But memory also reached into questions it had no business answering.
questions about a fact recalled it correctly
unrelated questions still drew on memory
Memory you didn't need is still disclosure. Relevance is a consent problem.
So that became the next design problem. The assistant now reads the recent conversation to resolve references, topic changes and corrections, searches with a specific subject, and asks when something is unclear. Sources reused from earlier answers are rechecked and capped. That release shipped on 19 October and is being judged in everyday use. This was a small synthetic set, not a claim of 100% accuracy.
Nothing ships
on its own word.
My rule: no release installs without a passing independent review. The conversation release needed one fix before it passed. The next feature, durable progress notes, went through three reviews and five fixes before it was confirmed and installed.
A defect worth learning from
Withdrawing a later correction could make an older value look current again. The new rule: undo never silently restores. Bringing a value back takes an explicit new correction.
What's proven.
What isn't yet.
Proven in my own use
- Permitted automatic recall across chats
- Memory controls in one place
- Original words preserved and linked to answers
- Every release independently reviewed before install
Not yet
- No external users yet
- Relevance is improved, not solved
- Imported chat history is out of scope
- Progress notes capture answers, not every step yet
What I'd test with real people
I haven't run this yet. The study I'd run: a few people resuming real work. Can they tell where an answer came from, choose what memory may use, and recover from an irrelevant recall? Success is defined before the first session.
Next case study
Memory you
can trace.
Saving one useful idea and getting its original words back.