Inspiration
I've been building a much larger local AI assistant for a long time. While working on it, one question kept bothering me:
If an AI remembers something about me, how do I know what it remembers?
Most assistants can remember things, but you usually can't inspect that memory, verify it, or prove that it stopped being used after you deleted it.
I wanted to build a small demo that focuses only on that problem.
Instead of showing another chatbot, I wanted to show what trustworthy AI memory could look like.
What it does
The demo shows the complete lifecycle of one memory.
A synthetic preference is proposed. The user can approve or reject it before it becomes usable.
If it is approved, the demo records exactly which memory was selected as context for the prompt. After the memory is revoked, it records another snapshot showing that the same memory is no longer included.
Everything can be tested completely offline without an API key.
If the user explicitly enables a live GPT-5.6 request, the demo performs one direct OpenAI call. It displays “GPT-5.6 used” only when the provider response itself reports a GPT-5.6 model. A configured model name alone is never treated as proof.
How I built it
The demo is a self-contained FastAPI application with a simple HTML interface and an in-memory SQLite database.
One of my goals was to make judging easy. It runs locally, uses only synthetic data, requires no installation of the larger assistant, and works without an API key.
I used Codex throughout development as an implementation and review partner. It helped me:
- isolate the demo from the larger project;
- implement the memory trust flow;
- write and run tests; and
- repeatedly review the code for privacy, correctness, and edge cases.
The product decisions were mine: what problem to solve, how consent should work, where the privacy boundary should be, and what evidence should be required before claiming that GPT-5.6 was actually used.
Challenges
The hardest part wasn't generating AI responses.
It was proving things.
Requesting GPT-5.6 doesn't prove that GPT-5.6 actually generated the response. Deleting a memory doesn't automatically prove that it stopped being used.
Most of the work went into making those claims verifiable instead of assumed.
What I'm proud of
I'm most proud that the demo stays focused.
Instead of trying to demonstrate everything my larger assistant can do, it demonstrates one idea from beginning to end:
- Approve a memory.
- Use it.
- Revoke it.
- Verify the result.
I'm also happy that the same experience works offline without an API key while still supporting a real GPT-5.6 demonstration when explicitly requested.
What I learned
Working on this made me realize that AI memory isn't only about remembering more.
It's about giving users evidence that the system behaves the way it claims.
Trust comes from being able to inspect and verify the memory lifecycle, not from the model making promises.
What's next
This demo represents one small part of a much bigger vision.
I want to apply the same trust model across a complete local AI assistant, where memories are always visible, user-controlled, traceable, and revocable instead of being hidden inside prompts.
Build Week scope
The larger local assistant already existed before Build Week.
The Build Week submission is the new standalone Memory Trust Demo created during the event. It includes the focused trust workflow, offline mode, optional GPT-5.6 integration, provenance checks, tests, and documentation.
I'm not submitting the larger project—only this new demo.
Log in or sign up for Devpost to join the conversation.