AreYouAI

RUAI answers one question, is this real?, for older people navigating social media. A video on YouTube or Facebook: was this made by AI? A message on Messenger or Instagram: is this a scam? A story pasted from anywhere: does it hold up?

The product turns three different detection problems into one answer: a risk level, the evidence behind it, and what to do next.

We built RUAI at GTC 2025 in Washington, DC, where it won the hackathon. The prize was a GPU signed by Jensen Huang.

My parents discovered social media a couple of years ago. They arrived twenty years late to a place that has spent those twenty years learning how to be convincing.

The product question wasn’t can we build an AI detector? It was can we help someone decide whether what they are looking at online is real? That distinction changed the product.

Lately, my teammates and I came across a fake profile that used a relative’s photo and name, claimed she was stranded abroad, and asked for $400 in gift cards. A generated video can make a news presenter appear to recommend an investment she never mentioned. A message or an email from “Facebook Support” can threaten account deletion unless someone confirms their details immediately.

The signals are different. The decision is the same: should I trust this? And for an older person, identifying the problem is only half the job. The useful product has to answer the next question too: what should I do now?

Our first version was essentially three AI demos: a deepfake detector, a scam detector, and a story checker. They shared a repository, but not a product model. They returned different response shapes, stored different data, and drove separate UI. That architecture made the technical demos work. It made the product incoherent.

The key engineering decision was to introduce a single domain object. Every analyser produces the same Verdict: a risk level, a score, a plain-language headline, the evidence, and recommended next steps. The models can be completely different. The product contract isn’t.

That meant the same Verdict could drive the chat warning, the video overlay, the popup, the website and the family view. One domain model, five surfaces. That was the change that turned three detectors into one product.

A detector naturally wants to say “73% likely fake”. That is useful to a model engineer and surprisingly poor UX for someone deciding whether to send money. We replaced the primary output with three actionable states. Safe (nothing suspicious was found), Be careful (there are signals worth checking before acting), and Do not trust (stop and verify independently). The score still exists, but it is secondary.

That forced a harder problem: confidence. A model producing a number doesn’t mean the number deserves to be trusted. We added calibration so the displayed score is capped by the evidence available. With no meaningful signals, the ceiling is 0.15. That prevented a real failure mode in early testing, where ordinary cooking videos were flagged simply because the model was overconfident.

The target user wasn’t “everyone who uses the internet”. It was someone who might not know what a deepfake is, might not recognise a phishing pattern, and might be reading the warning on a phone. So the interface has hard constraints:

• 1rem minimum body text: Sized in rem with the age of the reader in mind, so type scales with the screen and with whatever the reader has already set in their browser. A floor, not a default; nothing in a verdict renders smaller.
• 3rem minimum targets: Also in rem, so buttons grow with the text rather than staying fixed while the label around them scales. Every action stays reachable without precision aiming.
• Colour is never the only signal: Every state carries an icon and a written label alongside the colour, and all motion respects prefers-reduced-motion.
• Instructions, not diagnoses: Actions are written as things to do. The same verdict system powers extension, popup and website, so there is only one RUAI to learn.

Evidence, then an action

RUAI doesn’t just tell someone what to believe. It shows why. For a video, that means evidence drawn from consecutive frames rather than a single image, because generated video often looks convincing in one frame while inconsistencies become visible across a sequence. For messages, the analyser weighs impersonation, urgency, requests for money or credentials, suspicious payment routes, and account context.

For pasted stories, the language deliberately avoids pretending the model has proven something it cannot prove. If the system cannot verify a claim it says could not be confirmed, not false. Detection is not proof, and the product language has to preserve that distinction even when the underlying model wants to produce a binary answer.

A warning on its own is not enough. Imagine a message claiming a grandson is in jail and needs money immediately. “Likely scam” is useful, but the product should continue: don’t send money; don’t use the number in the message; call your grandson on the number already saved in your phone; if you can’t reach him, contact another family member directly.

Family view, without surveillance

There is a real tension here. If a family member is helping an older parent avoid scams, they need visibility. But giving them a complete history of every message, video and website that person receives creates a different problem: surveillance.

So the family view shows a weekly summary of what RUAI protected against, what verdict it gave, and what happened next. It does not record every ordinary message. The activity log is local, git-ignored and erasable from the UI, and the user is told when the family view is updated.

The analysis itself still calls out to hosted models. The future plan is to make the whole app run locally, with the LLMs running on the user’s own machine, at which point nothing about a parent’s messages needs to leave the house at all.

The extension and website cannot simply share assets, because of extension isolation constraints. So design tokens live in one source of truth and are synchronised into the extension by a script that also runs as a CI guard. Small constraint, but an important product-engineering lesson: the design system has to respect the deployment architecture.

Every analyser still returns the same contract. The models can disagree about how they got there. The product cannot:

type Risk = "safe" | "careful" | "do_not_trust"

type Verdict = {
  risk: Risk
  score: number        // capped by the evidence available
  headline: string
  evidence: string[]
  nextSteps: string[]
}

github.com/shreyas-sreedhar/are-you-ai

The biggest lesson wasn’t about deepfake detection. It was about product boundaries: drawing the architecture around the user’s decision rather than around the AI capabilities: input → analysis → evidence → verdict → action.

That abstraction made the system easier to extend and the UI dramatically more consistent. It also produced a better answer to a question that comes up constantly with AI products: what happens when the model is uncertain? Instead of hiding uncertainty behind a score, RUAI makes uncertainty part of the product.

RUAI is not a truth machine. It can identify patterns associated with generated media, suspicious messages and unverifiable claims. It cannot prove something is true simply because a model found no suspicious signals. The hard limitations are part of the product definition, not footnotes: video analysis uses a short frame burst; detection signals can be ambiguous; article checking has no retrieval layer; chat DOM scraping is inherently brittle; and local-first family protection requires a family member to set it up.

The honest promise is smaller: when something online asks an older person to believe it, RUAI helps them pause, understand why it looks suspicious, and choose a safer next step.

That was enough to take a collection of AI detectors and turn it into a product we could ship, and enough to win 1st place at GTC 2025 in Washington, DC. Repository and setup: github.com/shreyas-sreedhar/are-you-ai.