Debrief is not a PDF chatbot — it recovers decisions with citations

An engineer built Debrief, a tool for OpenAI Build Week 2026 that extracts structured decision briefs from documents and provides cited answers to follow-up questions. The system uses FastAPI, PostgreSQL with pgvector, and OpenRouter to parse documents, generate embeddings, and run RAG chat, with a React frontend on Vercel and API on Railway.

Teams rarely lose information because they lack documents. They lose it because decisions, rationale, owners, risks, and dates are buried across notes, launch plans, and transcripts. I built Debrief for OpenAI Build Week 2026 https://openai.devpost.com/ to recover those as a structured Decision Brief , then let you ask follow-ups that still point at the source. demo@debrief.app / DemoBuildWeek2026 workspace: Launch Planning A generic “chat with your PDF” answers in paragraphs. Debrief answers in rows : Then you can ask: What did we decide about pricing and why? and get a streaming answer with excerpts — not a hallucinated memo. User → React Vite ↓ REST + SSE FastAPI ├ JWT auth ├ document parse PDF / DOCX / TXT ├ embeddings → PostgreSQL + pgvector ├ Decision Brief structured extraction └ RAG chat cited follow-ups ↓ OpenRouter free models Frontend is on Vercel. API is on Railway. Database is Neon. 1. Extraction, not summarisation. The brief is a schema decisions, risks, owners . The model fills that schema. A blob of “summary” is a failure. 2. Citations on every claim. If a row cannot point at a chunk, it should not look as confident as one that can. 3. Stale briefs. If the docs change after you saved a brief, the UI tells you to regenerate. Otherwise you trust last week’s launch call. 4. Isolation. Workspaces keep one project’s notes from leaking into another. That is the product: recover the decision, then verify it against the source. I am an AI full-stack engineer React / Next.js / FastAPI / RAG . Portfolio: yatharthsharma.vercel.app https://yatharthsharma.vercel.app .