What we're building

A pipeline that turns world mythology into a narrated video for every story — and the logbook of building it.

The goal: a video for every story

StoryVault is a pipeline that turns the world’s mythology — starting with Hindu mythology — into narrated video stories, automatically and at scale. The north star is simple to say and hard to build: one finished video per story.

How we got here

It didn’t start as video. The product has evolved, driven by who’s actually watching:

  1. A simple comic. The first version was a static illustrated comic — research a canonical story, cast consistent characters, write a script, lay it out into panels, generate the art.
  2. Kids wanted it read aloud. The clearest feedback came from children reading it: they wanted narration. So we added a voice — a narrator plus per-character voices — and the whole audio pipeline that comes with it.
  3. Slideshow videos (where we are now). Panels + narration + sound naturally want to be watched, not paged through. So the current step is slideshow-style videos: the panels, timed to the narration, with sound effects and music.
  4. A video per story (where we’re going). The end state is a real video for every story in the tree — the slideshow is the bridge to it.

What you’ll find here — and what you won’t

This is a logbook of experiences and the solutions we came up with — the problems of turning old stories into automated, narrated, watchable content at scale, the dead-ends, and the approaches that finally worked.

What you won’t find is our tech stack, our tools, or our code. That’s on purpose. The interesting part was never which library or model we used — it was the thinking: how we framed a problem, why the obvious fix backfired, and the idea that got us out. Those lessons travel; they should be useful whatever you’re building on. So the posts stay at the level of ideas and decisions, not implementation.

Why this logbook exists

The demo is easy to show; the interesting part is everything that broke on the way there, and I keep losing those stories. So this is the logbook — told in the order it actually happened. Every post is a problem → the insight → the solution, and posts get revised over time, because in a system like this a fix often becomes the next problem. When that happens I append to the post’s Update log rather than pretending the original was wrong.

Posts go out one at a time, in the order things actually happened.

Colophon

This devlog is written by an LLM (Claude), working from my notes, logs, and project context. I set the direction, decide what’s worth telling, and edit; the model does the drafting from the real build history. Calling that out feels more honest than pretending otherwise — and how to write with an LLM instead of being written by it is part of what I’m figuring out here too.