The Answer Looked Right. That Was the Problem.

I started building The Verifier because of a slightly uncomfortable thought:

What if an AI gives you a perfectly written answer based on yesterday's truth?

Not a hallucination. Not an obviously fake source. Just an answer that used to be correct.

That felt more dangerous.

A polished lie is easy to fear. An outdated fact wearing a confident suit? That one can quietly walk straight into reports, presentations, articles, and important decisions.

So I decided to build something that would not simply answer a claim.

It would argue with itself first.

Meet The Verifier

The Verifier is an evidence-first research assistant for public claims.

You give it a claim such as:

Verify that Brian Niccol is the CEO of Starbucks.

Instead of immediately producing a confident paragraph, it investigates the claim from two opposing directions.

One research lane looks for evidence supporting the claim. Another actively searches for credible evidence contradicting it.

This matters because normal search behaviour has a bias: once we find one convincing source, we usually stop looking.

The Verifier does not get that luxury.

It has to search both sides, place the evidence next to each other, and show its work.

Then Starbucks created the perfect plot twist

The Starbucks leadership example turned out to be a great demonstration.

One public source identifies Brian Niccol as Starbucks' current chairman and CEO.

Another Starbucks source names Laxman Narasimhan as CEO.

Both sources are real. Both come from Starbucks. Both look authoritative.

So which one should the system trust?

This is where the project became more than a fancy search interface.

The answer was hiding in the metadata.

Dates are boring—until they solve the mystery

Most people do not get excited about fields such as datePublished, dateModified, or ISO timestamps.

Honestly, neither did I.

But those tiny pieces of metadata became the detective of this story.

The Verifier extracts machine-readable dates from every source. It records which metadata field was used, preserves the original value, and normalizes the date to UTC.

Now the system can compare evidence deterministically.

It does not choose a source because it sounds more confident. It can explain that one source represents an older leadership announcement while another contains newer evidence about the company's current leadership.

That difference matters.

The conclusion is not merely:

Brian Niccol is CEO.

It becomes:

The claim is supported by newer public evidence. The conflicting source is legitimate, but outdated.

Suddenly, the contradiction is not something to hide. It is part of the explanation.

I wanted the disagreement to remain visible

A lot of AI tools clean up the messy middle.

You provide a question. Something complicated happens. A neat answer appears.

Magic.

Also slightly terrifying.

I wanted The Verifier to show the messy middle.

The interface keeps the supporting and conflicting evidence in separate lanes. Each source displays its role, URL, relevant statement, and date information.

The user can inspect why the system reached its conclusion instead of being asked to trust a glowing confidence score.

Because “97% confident” sounds impressive, but it does not tell me whether the model checked last year's announcement against today's leadership page.

Evidence does.

The voice feature fought back

I also wanted the experience to feel conversational.

The original idea was simple: click Speak brief, say the claim, and continue asking questions naturally.

The browser had other plans.

At one point, the button barely behaved like a button. Then voice mode required clicking it repeatedly. Even worse, every new interaction felt like the previous conversation had been erased from existence.

The Verifier had the memory of a goldfish with Wi-Fi.

That forced me to rethink the feature.

Voice could not be a one-shot transcription gimmick. It needed to be a continuous conversation where the active claim, collected sources, and date resolution remained available for follow-up questions.

I also added text as a permanent fallback because demos—and browsers—have a wonderful sense of dramatic timing.

The agent can research. It cannot press Save for you.

This became my favourite part of the project.

After completing the investigation, The Verifier does not automatically store the result.

It asks the user for approval.

That is not just a polite message in the interface. The restriction is enforced on the server.

The server creates a one-time approval token and refuses to persist the dossier until explicit approval is received. Export remains locked as well.

If the user chooses to keep investigating, nothing is saved.

Only after server-confirmed approval does the dossier become permanent and downloadable.

The system can investigate, compare, and explain.

The final decision still belongs to a human.

Of course, the build was not a straight line

The first UI used fictional “Maya Chen” and “Northstar AI” evidence while the backend used the real Starbucks case.

Very coherent. Absolutely no notes.

That mismatch had to go.

Then came GitHub authentication, voice bugs, disappearing conversational context, provider configuration, Groq setup, and a Daytona API key that continued rejecting me like it had a personal grudge.

Some parts worked immediately. Several parts worked only after I stopped assuming they worked. A few parts smiled during testing and broke the moment I opened the demo.

That is the real version of building for a hackathon.

It is not one cinematic montage with energetic music. It is a series of tiny mysteries, questionable browser tabs, and commits that begin with the word “fix.”

But each problem improved the project.

The fictional demo became a real public case. The voice button became a conversation. The date field became an explanation. The approval message became a server boundary.