Legal
A case description in, a finished video out, learning from corrections
A retrieval system that answers only from firm documents and returns citations, wrapped in a video pipeline, with a correction loop that no model closes on its own.
Client: A law firm producing client-facing case explainers
System flow and narrative
Attorney review: Accepted. Reviewer decision: Approved. Path: Case submitted, then Documents dropped, then Knowledge base queried, then Downloaded, file by file, then Answer with citations, then Chunked and embedded, then Script assembled, then Avatar video generated, then Attorney review, then Video released.
A case description in, a finished video out, learning from corrections: system flow
Edges: live is a thicker, full-opacity, travelling dashed line; not taken is a thinner, dimmed, solid line. Nodes: live is a thicker, full-opacity outline; not taken is a thinner, dimmed outline. Color is never the only signal.
01
A case description in, a finished video out
An attorney submits a case description through a purpose-built interface and the system produces a finished video: avatar, background footage and burned-in subtitles, with no manual production step anywhere in between. What makes this worth publishing is not the video generation, which is a service call, but everything that happens before it: the script the video is built from is not written from the model's general knowledge.
02
Answering from the file, with citations
The legal reasoning agent queries the knowledge base by semantic similarity and is instructed to answer strictly from retrieved documents, never from general model knowledge, and to return citations so any claim can be traced back to its source. That is the posture legal work requires: an assertion an attorney can check, not a fluent guess that happens to sound like one. The citation requirement is what turns review from a matter of judgement into a matter of looking something up.
03
Feeding the knowledge base without touching a database
Case law, precedents and firm documents are dropped into a Drive folder, and an ingestion pipeline downloads, extracts, chunks and embeds them without anyone touching a database. It processes file by file rather than in bulk, specifically to avoid memory blowouts on large uploads. It is the same Qdrant store the reasoning agent queries, so a document added here is answerable, with citations, on the very next case. That choice looks like a small implementation detail and is actually the difference between a knowledge base a firm can keep feeding and one that fails the first time somebody uploads a full case bundle.
04
The loop a model does not close by itself
When an attorney marks an answer wrong or incomplete, the correction is captured along with the session, the original query and the model's response, and stored for review. Only when a human approves that correction does it get chunked, re-embedded and written back into the knowledge base. The system improves from real corrections, and a person decides what counts as a correction. A loop that wrote every piece of attorney feedback straight back would be a system that learns from whoever was most recently annoyed with it.
The branch logic, as a table.
| Condition | Then | Why |
|---|---|---|
| Attorney review is Accepted | Video released | |
| Attorney review is Marked incomplete | Correction captured | captured with the session and the original query |
| Attorney review is Marked incomplete | Correction reviewed | |
| Attorney review is Marked incomplete, and Reviewer decision is Approved | Written back to base | only an approved correction is re-embedded |
| Attorney review is Marked incomplete, and Reviewer decision is Not approved | Stored, base unchanged | |
| case law, precedents or firm documents | Downloaded, file by file | |
| one file per run, never batched | Chunked and embedded |
The stack.
| Layer | Tools |
|---|---|
| Orchestration | n8n |
| Vector store | Qdrant |
| Language model | OpenAI |
| Video generation | HeyGen |
| Review and storage | Airtable |
| Documents | Google Drive |
| Interface | Custom submission UI |
Safeguards.
- The reasoning agent answers strictly from retrieved documents and never from general model knowledge.
- Every claim returns citations, so an attorney checks an entry rather than trusting a fluent summary.
- Ingestion processes one file at a time rather than in bulk, to avoid memory blowouts on large uploads.
- A correction reaches the knowledge base only after a human approves it, so the system cannot learn from an unreviewed complaint.
- Corrections are stored with the session, the original query and the model's response, so a reviewer sees what was actually asked.
Before and after.
- Video production
- Before: Scripted, recorded, edited and subtitled by handAfter: A case description in, a finished video out, subtitles burned in
- Knowledge base upkeep
- Before: A developer touching a database to add a precedentAfter: A document dropped in Drive is downloaded, chunked and embedded automatically
- Answer traceability
- Before: A fluent summary an attorney had to verify from scratchAfter: Citations back to retrieved documents, so any claim can be checked
- Corrections
- Before: Noted in a thread, and lostAfter: Captured with their session, reviewed, and written back on approval
- Large uploads
- Before: A bulk import that could exhaust memory partway throughAfter: File-by-file processing that completes
This is one delivered system, published in full. See how we build AI automation
Want this on your own stack? See our n8n automation agency page.
Start a conversation
Tell us what you’re building.
Share the essentials and we’ll reply within 4 hours with a real next step, not an auto-responder.
What happens next
- We reply within 4 hours, from a real person, not an auto-responder.
- A short scoping call to understand the goal, constraints, and timeline.
- A fixed-scope discovery sprint: a working prototype and a written estimate.
- info@irenictech.com
- Office
- Austin, TX, United States
- Hours
- Mon–Fri · Async + scheduled calls