Trustify

Inspiration

Three of us are university students, and one of us moved cities for school this year so we didn't have to imagine this user. Every university says its graduates get great jobs, every listing says the rent is fair, and at eighteen you make the biggest decisions of your life so far on information that is almost entirely marketing. Our reframe came early: "is this true?" is unanswerable, but "where did this number come from, and who benefits if you believe it?" is almost always findable. So we stopped trying to score truth and started tracing where claims come from.

What it does

Paste a link, a claim, or a youtube video about graduate employment, a rental listing, a job offer and Trustify traces it back to a real source. You get the claims we extracted, what authoritative data actually says about each one, and evidence behind every conclusion as a clickable link. We never show a trust score; every result is a classification with a reason attached, because a percentage is something a student can read but not act on. We can also tell "outdated" apart from "false" a claim can have been accurate when published and simply stopped being true. Every report ends with a short list of what to check before you commit, because first-years don't just lack information, they lack knowledge of what to ask.

How we built it

We spent the first hour writing no code just a CLAUDE.md of invariants and a frozen contracts.py defining the one data shape every part of the system speaks. The architecture is three layers where only the outer two can change: adapters normalise any input, the kernel extracts claims and fans out analyzers in parallel, and analyzers each return Signal objects and nothing else. A Signal built without evidence raises immediately, so it's structurally impossible to show a number that isn't one tap from its source. Snowflake is the append-only system of record, and our most interesting query does point-in-time lookups against official series retrieving a value as it was published on a given date, which is what lets us separate outdated from wrong. FastAPI, and Next.js on Vercel.

Challenges we ran into

The hardest pivot moved our user to a student living alone for the first time, which quietly broke our two strongest signals both assumed a claim with a citation trail, and a rental listing or a job offer in a DM cites nothing. Absorbing it cost two lines in contracts.py and some new analyzer files; the kernel never moved, and we can show the diff. Work we thought we'd lost transferred instead: the near-duplicate detection built to catch one press release syndicated twelve times is exactly what catches one scam listing posted at three addresses.

Accomplishments that we're proud of

The architecture held through every pivot that isn't luck, it's the thirty minutes we spent on invariants before features. There is no trust score anywhere in Trustify, and every claim is one tap from its source, enforced at the type level rather than by good intentions. We treat "we don't have enough to judge this" as a real shippable result, which is uncomfortable at a hackathon and correct for a user who can't afford to be misled.

What we learned

We expected to be rewarded for building fast and were actually rewarded for building boring: a frozen contract, strict directory ownership, scoring weights in config rather than code. Three people can genuinely work in parallel if and only if they agree on the data shape first. We also learned that the honest answer is harder to build than the confident one, and that naming a specific user settles design arguments instantly: "five tabs or one collapsed section?" has an obvious answer once you know a college student has five seconds between lectures.

What's next for Trustify

The honest bottleneck isn't the model, it's coverage: we can only verify a claim if something authoritative exists to check it against, and right now that library is thin. So the next real work is connecting the datasets that already exist and nobody bothers to join graduate employment and earnings by program, local rent by postal code, corporate registries, labour statistics. Each one we add turns a whole category of claim from unverifiable into answerable, and the marginal cost of the next one falls, because the kernel doesn't change when a source does.

The second thing is that this should not stay an app people remember to open. Nobody visits a verification website before signing a lease. Trustify belongs where the decision actually happens in the phone share sheet, and as an API that housing portals, job boards and university services can call to show provenance inline. The report was designed from the start as a shareable, verifiable object rather than a screen inside our product, which is what makes that possible without a rewrite.