TrustLens Inspiration My YouTube subscriptions became my main source of learning, but the feed optimizes for watch time, not understanding. If I wanted to know what a creator actually said about a topic, I had to scrub through hour-long videos, and even then I had no idea whether the claim was well-supported or just confidently delivered. Search engines gave me the whole internet, not the handful of people I actually trust. That gap felt like the real "personal AI" problem: not another chatbot, but an assistant that knows my sources, answers from their words, and tells me how much to trust the answer. So I built TrustLens around one principle: cross-checked, never guaranteed true. What it does You add a few creators and set a trust level. Then you ask a question in a Chrome side panel: "What did this creator say about protein timing?" TrustLens returns the five most relevant moments, each with a title, creator, timestamp link, and a quote under 15 words. Every moment carries an automatic Legitimacy Report — supported, mixed, contradicted, insufficient, or opinion — backed by retrieved evidence and red-flag chips for sponsorship language, missing sources, and absolute claims. Contradicted results are shown last, with a warning. How I built it The stack is deliberately small: a vanilla-JS Chrome MV3 side panel, a Python FastAPI backend, and local SQLite. No build step, no cloud database, no telemetry. The pipeline is:

chrome.alarms re-ingests creators every six hours via YouTube RSS and transcripts, splitting them into ~60-second chunks stored with embeddings.
A question is embedded and matched against the top-20 chunks using numpy cosine similarity.
Nemotron, served through an OpenAI-compatible endpoint on Nebius, reranks to the top five. It runs inside a sandboxed Hermes agent at AGENT_URL when configured, and falls back to a direct LLM call otherwise.
Each moment goes through extract_claim → gather_evidence → judge → red_flags, with a claim-hash cache to avoid repeated work. Results are ordered by a transparent score: $$ \text{score} = 0.35\cdot\text{relevance} + 0.2\cdot\frac{\text{trust}}{5} + 0.3\cdot\text{legitimacy} + 0.1\cdot\text{consensus} + 0.05\cdot\text{recency} $$ where legitimacy maps verdict × confidence, and consensus is the share of supporting evidence among other trusted creators. Feedback nudges creator trust, so the system slowly learns whose word to weight. Challenges The hardest part was honesty. LLMs happily invent citations, so I filter every URL against retrieved evidence and return insufficient when the evidence is thin — a boring answer is better than a fabricated one. Relevance was the second challenge: pure cosine similarity surfaced chunks that were topically close but not actually answers. Adding an LLM rerank stage fixed most of it, at the cost of latency. Third, the architecture had to survive failure. Agent down, no transcripts, missing captions, an empty evidence set — each path needed a graceful default rather than an exception. Finally, the hardest constraint was the sandbox: I wrote and verified the logic with stubbed LLM and search calls, so live behavior against real YouTube, Nebius, and search APIs is the next milestone rather than a claim. What I learned I learned that retrieval quality dominates verdict quality — a good judge cannot rescue a bad chunk. I learned to treat the model as one unreliable component in a pipeline, not an oracle. And I learned that "always-on" is an architecture decision: periodic ingest, persistent memory, and local data are what make an assistant feel personal rather than rented. What's next Live end-to-end validation, more platforms, weighted evidence quality, and a test suite. The roadmap is simple: make the trust signal as trustworthy as the name promises.