TrustLens

TrustLens shows whether product claims like “10-hour battery life” are actually supported by evidence.

Comment

Inspiration

TrustLens started with a practical problem I was trying to solve at home.

I was designing a projection setup for my house and researching affordable projectors online. During that process, ChatGPT warned me to be careful with inexpensive projectors because many sellers exaggerate their brightness ratings.

That warning immediately stood out to me because I had already learned the same lesson the hard way. Cheap projectors are often advertised with impressive-looking brightness numbers, but those numbers may use unclear measurements, misleading terminology, or specifications that do not reflect real-world performance.

The important moment was not that ChatGPT recommended a better projector. It was that it recognized a common pattern of misleading product claims and warned me before I made another bad purchase.

That created the original idea behind TrustLens:

What if AI shopping tools focused less on recommending products and more on protecting shoppers from scams, exaggerated claims, and misleading listings?

At first, the concept seemed simple: analyze a product page and ask AI whether its claims looked suspicious.

However, that introduced another trust problem. A shopper should not have to blindly trust an unexplained AI answer about whether a product is trustworthy.

The idea therefore evolved beyond a single AI prompt into a much more structured system.

TrustLens became an evidence-driven product credibility platform that evaluates individual claims, connects them to supporting or contradicting evidence, and explains how those findings affect an overall Trust Score.

The principle at the center of the project is:

The score summarizes; the evidence persuades.

What it does

TrustLens is a browser-based shopping assistant designed to help shoppers identify misleading, exaggerated, or unsupported product claims.

When a shopper opens a supported product page, TrustLens analyzes the listing and presents a clear Trust Score alongside an explanation of the most important findings.

For example, a projector listing might advertise:

“20,000 lumens”

TrustLens can identify that brightness claim, determine what measurement standard is being used, compare it against available manufacturer information or independent evidence, and warn the shopper when the claim appears misleading or lacks credible support.

TrustLens evaluates product listings at the claim level rather than relying only on star ratings, review counts, or general product popularity.

It can:

  • identify the product and selected variant;
  • extract important claims from the listing;
  • normalize claims into structured assertions;
  • connect each claim to supporting or contradicting evidence;
  • evaluate the reliability, independence, freshness, and relevance of that evidence;
  • distinguish harmful exaggeration from conservative understatement;
  • calculate a deterministic Trust Score;
  • show shoppers which claims influenced the result;
  • explain why a claim appears supported, questionable, contradicted, or unresolved.

The shopper sees one clear Trust Score, an evidence-strength label, and expandable details for individual claims.

TrustLens is not intended to be another product recommendation engine. Its purpose is to help shoppers decide whether the claims being used to sell a product are credible.

How I built it

TrustLens was designed as an evidence-first system rather than a general AI opinion generator.

AI is useful for understanding unstructured product pages and evidence sources. It can help:

  • extract product claims;
  • interpret technical specifications;
  • normalize different units and terminology;
  • identify possible contradictions;
  • summarize evidence in language shoppers can understand.

However, AI does not directly decide the final Trust Score.

The score is calculated by a deterministic, versioned Rating Engine using structured inputs such as:

  • claim materiality;
  • evidence reliability;
  • evidence independence;
  • directness;
  • freshness;
  • product and variant match confidence;
  • supporting and contradicting evidence;
  • consumer impact;
  • unresolved questions.

This means the same evidence and configuration should always produce the same score.

The project architecture includes:

  • a Chrome extension built with TypeScript, React, WXT, and Manifest V3;
  • a Fastify backend API;
  • an asynchronous investigation worker;
  • shared runtime-validated contracts;
  • a deterministic Rating Engine;
  • PostgreSQL persistence;
  • immutable listing, claim, evidence, case-file, and rating snapshots;
  • fixture-backed investigators for reliable testing and demonstrations.

The extension detects supported Amazon product pages, extracts normalized listing information, and displays the TrustLens interface directly alongside the shopping experience.

The backend coordinates investigations, evaluates claims, builds evidence case files, calculates ratings, and returns a public-friendly explanation.

For the hackathon MVP, I intentionally prioritized a complete vertical slice over broad production coverage.

The demonstration uses representative fixture-backed products that cover three important situations:

  1. a product with strong supporting evidence;
  2. a product containing a material contradiction;
  3. a product with limited evidence or unresolved identity.

These fixtures use the same contracts and Rating Engine that future live investigators will use, but they keep the demo reliable and avoid depending on fragile scraping or expensive AI calls during judging.

Codex and GPT-5.6 were used as engineering collaborators throughout the project. They helped translate the original idea into a structured architecture, define the claim and evidence models, scaffold implementation work, identify edge cases, review decisions, and build testing and deployment plans.

A key human decision was that AI should help investigate the evidence but should never own the score.

Challenges I ran into

Defining what “trust” means

Trust is not a single measurable property.

A listing can accurately identify a product while exaggerating its performance. It can contain several correct specifications and one highly misleading claim. A product can have thousands of positive reviews while still being marketed with false technical information.

I addressed this by treating a product listing as a collection of individual claims.

Each material claim receives its own evidence case file and conclusion before contributing to the overall rating.

Avoiding an unexplained AI verdict

The easiest implementation would have been to send a product page to an AI model and ask:

“Is this product trustworthy?”

That would create a fast demo, but it would not create a trustworthy system.

The result could change between model calls, be difficult to reproduce, and provide no inspectable reason for the score.

I instead separated responsibilities:

  • AI extracts and interprets information.
  • Evidence is stored with provenance.
  • Case files evaluate individual claims.
  • The Rating Engine calculates the score deterministically.
  • The interface explains the stored reasoning.

Matching the correct product and variant

Retail product pages frequently combine multiple sizes, colors, capacities, model years, and configurations.

Evidence about one variant should not automatically apply to another.

TrustLens therefore tracks both retail listing identity and normalized product identity. Cross-listing evidence can only be reused when product-match confidence is sufficiently high and no important variant conflicts exist.

Handling contradictions fairly

Not every inconsistency has the same meaning.

Suppose a product listing claims six hours of battery life, but reliable testing shows it lasts ten hours. The listing is inaccurate, but the shopper receives something better than promised.

That should not be treated the same as a listing promising ten hours when the product only lasts six.

TrustLens records both the direction of the inaccuracy and its likely consumer impact.

This allows the system to distinguish:

  • harmful overstatement;
  • favorable understatement;
  • neutral differences;
  • mixed findings;
  • safety-critical contradictions.

Controlling cost and infrastructure complexity

A complete product-investigation platform could become expensive very quickly.

Repeated AI calls, live web searches, broad crawling, multiple backend services, and large evidence stores would make an early MVP difficult to operate.

I reduced cost and complexity by:

  • caching investigations and ratings;
  • avoiding duplicate work;
  • using fixture investigators first;
  • keeping the architecture modular without deploying microservices;
  • using PostgreSQL instead of introducing a graph database;
  • supporting fully local development;
  • designing a low-cost hosted option;
  • deferring features that were not required to prove the core idea.

Reducing the scope for the hackathon deadline

The complete TrustLens vision is much larger than what could be completed reliably during the event.

I had to separate the core innovation from the long-term platform.

The hackathon version focuses on proving one complete flow:

  1. identify a product listing;
  2. extract or load its claims;
  3. connect those claims to structured evidence;
  4. build case files;
  5. calculate a deterministic Trust Score;
  6. display the score and evidence to the shopper.

Features such as broad live crawling, subscriptions, community contributions, full review-authenticity analysis, and cross-retailer support were intentionally deferred.

Accomplishments that I am proud of

I am proud that TrustLens does not simply ask shoppers to trust another AI-generated answer.

The project was designed around explainability and reproducibility from the beginning.

TrustLens includes:

  • claim-level reasoning;
  • evidence provenance;
  • deterministic scoring;
  • directional contradiction analysis;
  • product and variant identity tracking;
  • internal confidence calibration;
  • immutable historical rating snapshots;
  • benchmark investigations;
  • clear separation between public scores and internal confidence.

I am especially proud of the Case File concept.

Every important product claim can have its own structured record containing supporting evidence, contradicting evidence, unresolved questions, and a conclusion.

This means the final Trust Score is not an isolated number. It can be traced back to the claims and evidence that produced it.

I am also proud that the architecture remains practical for a very small team.

TrustLens is graph-native as a domain, but the MVP does not require a graph database, Kubernetes, or a collection of microservices. The system preserves clean boundaries while remaining inexpensive and manageable.

What I learned

I learned that explainability cannot be added to an AI product at the end.

If a system only stores its final answer, it cannot later provide a trustworthy explanation. The relationships between claims, evidence, conclusions, and ratings must be part of the data model from the beginning.

I also learned that trust and confidence are different concepts.

A product might receive a high Trust Score based on very limited evidence, or a moderate score based on strong evidence. Those situations should not be communicated in the same way.

TrustLens therefore exposes one public Trust Score while separately tracking internal confidence and presenting an evidence-strength label.

Another lesson was that AI is often most useful as an investigator rather than an authority.

AI can search, extract, normalize, compare, and explain information. Deterministic code can then apply consistent rules to those structured findings.

I also learned that the direction of an error matters. A conservative understatement and a harmful exaggeration are both inaccurate, but they do not create the same risk for a shopper.

Finally, I learned that a smaller complete product is more valuable than a large collection of unfinished components.

The fixture-backed vertical slice gives us a reliable way to demonstrate the full TrustLens reasoning process and creates a foundation for future live investigations.

What's next for TrustLens

The next stage is to replace fixture investigators with live evidence collectors while preserving the same contracts and deterministic Rating Engine.

Planned improvements include:

  • live AI-assisted claim extraction from Amazon pages;
  • manufacturer manual and specification investigators;
  • certification and regulatory database checks;
  • professional testing and review evidence;
  • improved product and variant matching;
  • historical listing-change detection;
  • review-pattern and authenticity analysis;
  • support for additional retailers;
  • TrustLab, an internal investigation and quality console;
  • community evidence and correction workflows;
  • benchmark suites for additional product categories;
  • product credibility histories over time.

A major future use case is evaluating projector listings like the ones that originally inspired the project.

TrustLens could identify when a seller uses vague brightness numbers instead of recognized standards such as ANSI lumens, explain the difference to the shopper, and show whether independent evidence supports the advertised performance.

The long-term goal is for TrustLens to become a credibility layer for online commerce.

Instead of asking shoppers to trust product pages, sellers, reviews, or AI summaries by default, TrustLens helps products earn trust through evidence.

Built With

Share this project:

Updates