Exa gives you evidence, not verdicts

Where I started

I run California Black Stories, a content project about Black history in California. Accuracy is the whole brand. One wrong date in a caption and the comments fill up with corrections, so every post gets reviewed before it goes anywhere.

I also needed a demo for the Exa Developer Advocate application. I decided to build something I would actually use: a tool that proposes historical claims, checks them against real sources, and produces a finished, export-ready post. A toy demo would not have taught me anything. A real tool would.

How I built it

The app is a Next.js project with one API route per step. OpenAI proposes historical claims from topics I enter, automatically scoping each one to California. Exa retrieves sources with highlighted excerpts for the claim I pick. Then, instead of trusting those sources, a separate audit step has the model judge each part of the claim against the excerpts as supported, unsupported, or contradicted.

From there I compose the post: an editable fact, an AI-generated caption with exactly five hashtags, a call to action, and a live 1080 by 1080 preview I can download as a PNG. Finished facts save to a history with their sources and timestamps, and new claims get cross-checked against that history.

Following the workflow

A claim moves through three stages, with me deciding when it moves forward.

1. Propose claim ideas

   I enter topics. The app asks OpenAI for historical claims, appending "in California" to any topic that does not already mention it. I pick one to work with.

2. Verify against Exa evidence

   Exa returns sources with highlighted excerpts. The audit labels each part of the claim supported, unsupported, or contradicted, and the cross-check flags overlap with facts I have already saved. If the audit is mixed or contradicted, I can apply a suggested correction that rewrites the fact from the findings.

3. Compose and export

   I edit the fact, generate or write the caption and call to action, and download the 1080 by 1080 image. Saving stores the fact, caption, sources, and timestamp to history. Nothing posts automatically.

Under the surface

The page is a single React component. Each step calls its own Next.js API route, and the routes call OpenAI or Exa. On my machine the routes shell out to vault-backed skill CLIs; on a deploy they would call the APIs directly with environment variables. History reads and writes go through one shared store module: Supabase when the project URL and service key are set, a local JSON file when they are not.

Two things sit in front of everything. A middleware checks a password before serving any page or API route, and each AI-backed route rate-limits requests per IP. The image export runs in the browser with html2canvas, scaling the rendered card up to exactly 1080 by 1080.

The browser page calls seven Next.js API routes. Middleware applies an APP_PASSWORD login gate and per-IP rate limits before any route runs. The claims, audit, fix, and caption routes call OpenAI; the verify route calls Exa for sources with highlighted excerpts; the history and crosscheck routes go through a shared store that uses the Supabase cbs_facts table when environment variables are set and falls back to a local JSON file. Image export happens client-side with html2canvas at a computed scale for a 1080 by 1080 PNG.

Decisions visible in the code

What testing changed

The app was tested the same day it was built, and testing drove most of the design. The iteration trail:

The Pacific Appeal catch created the audit step. The first version trusted Exa results at face value; the contradicted "first" proved that was not safe, so evidence now gets judged part by part before anything is composed.

Composing kept showing stale content. Verifying a new claim left the previous caption in place, so Verify now clears it. Applying a correction did not update the image text, so the correction rewrites the fact field and the live preview follows it. Captions generate from the corrected fact, not the original claim.

State resets became a rule. Selecting a new claim clears the sources, conflict banner, and evidence check while keeping the claim in the fact field. Generating claims clears the compose fields. Reusing a fact from history clears the previous evidence check. Each action now starts from a clean slate.

The five hashtags are enforced in code, not wished for. The model returns hashtag names as a JSON array, and a helper strips stray characters, pads with defaults, and slices to exactly five before appending them to the caption.

The public deploy got hardened before it existed. Supabase replaced the JSON file as the history backend, the password gate went in front of everything, and rate limits went on the AI routes, all before the app had a public URL.

Mobile got a real pass. The two-column layout collapses under 860 pixels, the preview card scales with container query units while the PNG export stays 1080 by 1080, form fields use 16 pixel type so iOS does not zoom on focus, and the app got a viewport tag and a favicon.

What the evidence says

The account above was verified against the deployed app on September 26, 2026.

Claim to correction flowverified

The Pacific Appeal 'first' claim returned contradicted on the 'first' part with the rest supported. Applying the suggested correction rewrote the fact and the live preview. The caption generated from the corrected fact with exactly five hashtags, and the downloaded PNG was 1080 by 1080.

Cross-checking the same claim against a saved Mirror of the Times fact correctly flagged the conflict, while a saved California Eagle fact correctly produced no conflict.View evidence ↗

Supabase round tripverified

Save, list, and delete all work from the deployed URL against the Supabase backend.

The cross-check reads through the same history store, so it operates against Supabase on the deploy.View evidence ↗

Deployed behaviorverified

The password gate prompts for credentials before serving any page or API route. Verify, caption generation, image download, and history all work from the public URL.

Rate limiting has not been exercised under real abusive traffic; it stands as a second layer behind the password gate.View evidence ↗

What this version represents