Inspiration
Teams rarely lose the whole meeting. They lose the decision inside it.
Someone remembers that SSO came up. Someone else remembers a different pricing decision. Months later, nobody can say what was agreed, why, or whether a later meeting quietly changed it.
We wanted to build something more useful than a meeting summarizer. Undertow is a decision audit. It keeps a durable record of commitments and points out when that record changes.
What it does
Undertow accepts an uploaded transcript or a browser recording. A recording is transcribed, then follows the same path as an uploaded transcript.
It extracts discrete decisions with an owner, assumption, category, and confidence. Each new decision is compared against the workspace's earlier decisions. Undertow can flag a contradiction, supersession, reaffirmation, or refinement, and it's just as willing to flag nothing, when two decisions are genuinely unrelated.
The result is a decision ledger, not a chat summary. Teams can inspect the source meeting, read why a relationship was flagged, resolve or reopen it with a note, and keep an immutable review history.
How we built it
Tracy built the frontend in React, TypeScript, and Vite: the ledger, meeting archive, recording flow, tension review, notifications, categories, profile, workspace views and Clerk authentication.
Waweru built the FastAPI backend: SQLite, Pydantic validation, workspace scoping, local recording storage, retries, lifecycle states, and the audit pipeline itself.
The live MVP runs on Groq. openai/gpt-oss-20b handles structured decision extraction and tension reasoning. whisper-large-v3-turbo transcribes recordings. We use Clerk for sign-in and keep all product data scoped to a workspace.
We made a few deliberate calls early. The extraction prompt includes examples that separate a real commitment from "we could consider this" or "should we do this?" The tension prompt requires a specific explanation, not a generic similarity label, and treats "no relationship" as a good answer when the evidence is weak. At this scale, we pass the full prior decision history into the reasoning call instead of adding embeddings or retrieval infrastructure. We also made recording converge into the transcript pipeline after transcription, so extraction, tension detection, retries, notifications, and failure handling all live in one place, not two.
Codex with GPT-5.6 was our build environment. It turned our product constraints into routes, models, fixtures, tests, integrations, and documentation. The human work was deciding what the product had to mean, and reviewing everything Codex generated against that bar.
Challenges we ran into
The hard part was never extracting text. It was deciding what counts as a decision.
A meeting contains questions, opinions, hedges, and unfinished discussion. We had to stop the ledger from becoming a list of every sentence someone said, few-shot examples, strict JSON schemas, Pydantic validation, and a synthetic ground-truth set kept the pipeline honest.
We also had to teach it the difference between a contradiction and an intentional change of direction. A price change can supersede an older decision. A later meeting can reaffirm it. A narrow retention rule can refine it. Those distinctions matter to a team actually reading the record.
Accomplishments that we're proud of
We built a complete path from source meeting to reviewable audit record.
Our Meridian fixture has five meetings with a planted contradiction, supersession, and reaffirmation. Our Undertow Labs demo fixture has 15 meetings, 30 decisions, four relationship types, categories, notifications, and retained recording assets.
We're also proud that the product is honest about its boundaries. It doesn't pretend that calendar integrations, billing, email delivery, or background jobs exist when they don't.
What we learned
Models need clear boundaries. Structured output helps, but prompt design, validation, fixtures, and cautious defaults matter just as much.
We also learned that a small architecture can still be a deliberate one. One pipeline for transcripts and recordings made the system easier to reason about. Full-history comparison was the right tradeoff for a demo-scale decision ledger, not the "correct" answer for every scale, but the right one for this one.
What's next for Undertow
Next, we'd add retrieval for larger decision histories, background jobs for long recordings and model calls, and object storage with real retention controls.
We'd also build real calendar and meeting-platform integrations, plus durable notification delivery. The core question stays the same either way: when a team changes a decision, can everyone actually see it?
Log in or sign up for Devpost to join the conversation.