A project page tells people what you have built. It doesn’t always help them find the part that matters to them.
Someone considering me for a project might want to know how my operations experience connects to software development, or what I learned from building an education platform. Those answers can span several pages and a CV.
I built the Digital Twin to make that exploration a conversation. Visitors can ask about my work in English or Turkish, follow up on an answer, and open the sources behind it.
What visitors can do
The assistant is part of this website. It draws on my published projects, articles, professional background, and reviewed public CV. It can help with questions such as:
- “What kinds of projects has John worked on?”
- “How does CareerTalkLab connect to his background in education?”
- “Which of those strengths is relevant to an AI product role?”
That last question is particularly useful: a conversation should let you say “those strengths” without restating everything. The assistant uses earlier messages to understand what you mean, then looks up evidence for the new answer.
“Digital Twin” is the project name. It is an AI guide to my documented work, not a person speaking on my behalf. It cannot make commitments, send messages, or change website content.
Making the answers checkable
A convincing answer isn’t enough if a visitor cannot tell where it came from. The central design choice was to connect answers to published information and make those sources easy to inspect.
For questions about my work, the assistant finds relevant material, prepares an answer, and checks that draft against the information it retrieved. It can revise the answer or decline when the evidence is insufficient. A separate check allows only citation links returned by its retrieval tools, helping prevent it from inventing a source URL or copying an incorrect link from an earlier message.
This also matters when a question calls for judgment. The assistant can explain why a documented experience might be relevant to a role, but that is an interpretation of the evidence—not proof that I have held that role or achieved an undocumented result.
What I built around the conversation
The chat window is the visible part of a larger system. Behind it are a searchable collection of public material, a way to process published content updates, and controlled access to project details and career history.
The assistant has five ways to look up information: search the public material, read my CV timeline, retrieve a project, list articles, or find contact options. These are read-only actions. Private drafts and unapproved CV material are outside its intended knowledge sources.
I also put limits on how much work it can do for one answer. It gets a small number of lookups and a fixed time limit, rather than continuing indefinitely. Request limits help manage use of the public service.
For readers interested in the technology, the website uses Next.js, Google’s Gemini models, Supabase for searchable information, WordPress for publishing, and Vercel for hosting. The technical case study explains how those pieces fit together.
What testing revealed
Scripted conversation tests and local runs exposed problems that the offline tests had missed. Some questions received an unhelpful fallback. In one Turkish test, a draft answer copied an outdated link from an earlier message. That local draft failed verification and never reached the public site. An ambiguous follow-up could stop without looking anything up.
Fixing those problems meant making the rules more explicit: look up evidence for each factual answer, use conversation history to understand the question, and take citation links from retrieved sources.
On September 14, 2026, all three targeted follow-up conversations passed on the deployment subsequently released to the public site. They covered the original strengths question and English and Turkish questions referring back to a project. The two project conversations used made-up earlier messages to test those references. Each answer used fresh retrieval, went through a verification step, and included working source links, though the strengths answer gave two strengths when asked for one. The release also passed 177 automated assistant tests.
These are useful checks, not a claim of perfect accuracy. Results in an earlier six-question evaluation improved from zero to three of six across two releases. The conversation histories differed between those runs, so they were not an exact like-for-like comparison. The later three follow-up checks were a separate, smaller test. Both the successes and failures are preserved in the public evaluation record.
What I learned
The most important work was deciding what the assistant should be allowed to claim, what evidence it needed, and when it should stop. A fluent answer can still be wrong. A working link can still be a poor source for a particular claim. Testing needs to examine the whole conversation, not just whether the service returns a response.
The current assistant can still give overly broad answers or struggle with questions that combine several sources. Its checking step is itself AI-based, and conversations do not persist across page reloads. The project is a working example of how to make an AI assistant more useful and accountable while keeping its limitations visible.
Try it
Open the chat on my homepage and ask about a project that interests you. Then ask a follow-up and open one of the source links to see what supports the answer.
Watch the demonstration below to see selected questions and answers. This silent screen recording includes English captions describing the on-screen conversation.
If the video does not play in your browser, you can read the recorded examples and open the full transcript. You can also explore the source code.