Chronicle // Revision Workspace

A cinematic state compiler that traces creative revisions through production history, proposes coherent repairs, validates invariants, and keeps final promotion human-controlled.

Comment

Inspiration

Film production is full of changes that look local but are not. Move a reveal from one scene to another, change a rainy night exterior to sunrise, or alter a costume state, and the consequences can ripple into dialogue, character knowledge, wardrobe, score, already-shot material, and downstream production decisions.

Most generative media tools are good at creating a new asset. They are much weaker at answering the production question that comes first: what else must change so the new creative choice remains coherent?

Chronicle was built around that gap.

What it does

Chronicle // Revision Workspace treats a film as a typed, versioned creative state rather than a pile of disconnected files.

A director proposes a revision. Chronicle turns that request into a structured revision patch, traces the affected production facts and dependencies, surfaces the blast radius, prepares candidate repair strategies, validates the facts that must remain true, and only then allows a human to promote a new production state.

The core workflow is:

  1. Production State — inspect the current scene, script facts, wardrobe state, sound cues, locked invariants, and production history.
  2. Revision Impact — enter a creative change and see which downstream scenes, facts, departments, and previously-shot assets are affected.
  3. Candidate Repair Studio — compare repair strategies instead of accepting the first generated answer.
  4. Validation — distinguish explicit PASS, FAIL, and UNKNOWN; missing evidence never silently becomes a pass.
  5. Human Promotion — the agent can discover evidence and recommend a repair, but the director controls the irreversible transition to the next production state.

Our demo scenario moves Maya's reveal from Scene 12 to Scene 18 while changing Scene 12 from a rain-soaked night exterior to a quiet sunrise. That single request is designed to expose downstream story, wardrobe, score, and continuity dependencies rather than produce an isolated visual edit.

Why this matters

A production revision is expensive when its hidden consequences are discovered late. Chronicle is designed for filmmakers, editors, script supervisors, VFX teams, and production crews who need to understand not only what changed, but what that change breaks and why.

The product's central idea is simple:

A film revision should behave more like a code change: understand the intent, compute the consequences, repair the dependent state, validate the invariants, and preserve an auditable history of what was promoted.

How we built it

Chronicle began as a design-system and workflow exercise in Google Stitch, where we developed a media-first interface inspired by professional DI/color-grading suites and script-supervision tools rather than a generic chatbot dashboard.

That design was exported into Google AI Studio Build mode as a full-stack Next.js / React / TypeScript application. The public build uses server-side Gemini integration and keeps secrets out of the browser bundle. Google AI Studio also provides the GitHub synchronization and hosted application path used for the project.

For the ClickHouse track, the architecture separates two different responsibilities:

  • Evidence discovery — the agent reads production facts and dependency evidence through ClickHouse.
  • Consequential promotion — a human-approved server action is responsible for appending the committed revision state.

That separation is deliberate: an agent may discover evidence and construct a repair manifest, but it does not get to turn its own recommendation into accepted production truth.

The ClickHouse data model is append-oriented and represents scenes, invariants, revisions, dependency edges, validation receipts, creative contracts, media artifacts, and audit events. The runtime integration is designed around the official mcp-clickhouse server for the read-only evidence plane, with a restricted application writer for human-authorized promotion.

Design decisions

We iterated away from an early dense dashboard into three persistent product surfaces:

  • Production State & Continuity Ledger
  • Revision Workspace — Active Simulation & Repair Dock
  • Revision Workspace — Committed Baseline

Media stays visually dominant. Color is used for real semantic transitions such as LOCKED, VIOLATION, CANDIDATE, and COMMITTED, rather than decorative status noise. We also removed fake success states from the implementation contract: CONFIGURED is not the same as CONNECTED, and missing validation is UNKNOWN, not PASS.

Challenges we faced

The hardest problem was not generating a polished interface. It was making sure the interface represented real runtime truth.

Early prototypes could visually claim that a query completed, a repair converged, or an invariant passed even when those states were only simulated. We therefore made runtime-state honesty a first-class design requirement and separated NOT_CONFIGURED, CONNECTING, QUERYING, QUERY_FAILED, READY_TO_PROMOTE, and COMMITTED states.

The second challenge was defining the authority boundary between an agent and a production system. We chose a read-only evidence plane plus a deterministic, human-authorized promotion path instead of giving the model unrestricted database write authority.

The third challenge was creative continuity itself. Experiments with multimodal references showed how easily identity, wardrobe, environment, and style references can bleed into one another. That led to a stronger Creative Contract idea: references and attributes should have explicit roles such as locked, mutable, advisory, or ignored, and generated candidates should be validated against those constraints before promotion.

What we learned

  • A visually convincing prototype is not the same as an evidenced runtime.
  • Creative generation becomes much more useful when it is downstream of causal production knowledge.
  • ClickHouse is a strong fit for append-oriented revision history and dependency analysis because the project needs to ask temporal and graph-like questions over production state, not just store chat messages.
  • Human approval is most useful at the meaningful consequence boundary — promoting a new production state — rather than interrupting every intermediate reasoning step.
  • A good cinematic AI product should make the media and the decision visible, not hide both behind a chatbot.

Current build

The public application and repository are live. The full-stack product shell, Stitch-derived interface, Gemini server route, and ClickHouse client layer are present. The final contest runtime path is being completed around Google agent tooling and the official mcp-clickhouse integration so that the judge-visible revision flow is backed by real production evidence rather than simulated receipts.

What's next

The immediate goal is one complete end-to-end proof: parse the Scene 12 revision, retrieve real evidence through ClickHouse, compute the bounded ripple, produce a repair manifest, require human promotion, append the committed event, and re-query validation state.

After that spine is proven, the same Creative Contract can drive richer Google-native image, video, and music repair previews without changing the underlying authority model.

Built With

Share this project:

Updates

Submission history