The Film Should Be the Interface

The missing object is the project

Most generative-media tools are organised around what their providers sell. The starting point is usually a model, an asset library, an Element, a prompt box, or a history of generations. That makes sense for a provider. Its product is access to a generation engine.

It makes less sense for a studio.

When I am making a short film, episode, trailer, or character piece, I am not really making “generations.” I am trying to make a coherent project. That project has a brief, a script, characters, locations, props, visual rules, shots, sound requirements, editorial decisions, and a release destination. A clip only matters because it serves one part of that larger structure.

Provider interfaces tend to leave that structure outside the tool. A reference image may sit in one library, a reusable character in another, a promising test somewhere in generation history, and the reason a shot was rejected in a chat or notebook. The provider remembers the transaction. The filmmaker has to remember the production.

Nodupon’s Project-First Cinema Studio is a working label for an internal system I am exploring to close that gap. It is work in progress, not a completed application and not a public SaaS product. The architectural thesis is simple: begin with the film, preserve its production memory, and treat generation providers as replaceable production services.

The intended flow looks roughly like this:

Project → brief and script → durable assets → shots → generations → selects → sound → edit handoff

That sequence changes what the software is for. It is no longer a thin wrapper around a model. It becomes a production ledger: a place where the state of the film remains legible even when the tools underneath it change.

Durable assets and a manifest of intent

The first design principle is durability. Provider URLs expire. Accounts change. Model versions disappear. Generation histories become difficult to search, and even a visible thumbnail may no longer explain which references, settings, or decisions produced it.

The studio therefore needs to treat local media and production metadata as the durable record. Images, video, audio, scripts, prompt drafts, approved outputs, and useful failures should be preserved under stable project storage. A database can track relationships, statuses, hashes, provenance, and review notes, but the media itself should remain ordinary, recoverable files rather than opaque blobs trapped in an application.

Each project then owns a manifest: not necessarily one giant document, but a machine-readable account of what the production uses. It links the project to canonical characters, locations, props, voices, reference bundles, shot definitions, generations, and selected takes. The important word is links. A recurring character should not be copied into every project until no one knows which version is authoritative. The master asset belongs in a shared library; the project manifest records the approved state or variant used in this film.

That distinction becomes especially useful for what providers call Elements. A provider-native Element may be an excellent reusable representation of a character or subject, but it is still a platform object. I want a provider-neutral logical Element above it: the durable production concept, such as a particular character in a particular costume or story state.

The logical Element can own its source references, continuity notes, approved uses, test clips, known strengths, and known failure modes. Beneath it sit provider bindings: the corresponding object or reference bundle for each service. If a provider disappears or a model works better elsewhere, the character does not vanish with the binding. The studio retains both the identity and the evidence needed to rebuild it.

Provider adapters, not provider-shaped productions

Once the project is the centre, providers become adapters at the edge of the system. Their capabilities still matter enormously, but they should not dictate the shape of the production record.

A useful adapter boundary has a small set of responsibilities: discover current capabilities, validate a request, translate project inputs into a provider payload, submit a job, poll its status, download the result, normalise errors, and register the output as a durable asset. The adapter should preserve provider-specific settings rather than pretend all models are identical, while presenting a consistent lifecycle to the project.

This is more than an abstraction exercise. Similar labels can conceal different rules. One model may accept a persistent subject object; another may accept only images or video references on each request. One route may support a character reference in image-to-video but not in text-to-video. Duration, aspect ratio, audio, resolution, and reference limits can vary by model and can change over time.

The correct response is not a universal form with dozens of controls. It is capability discovery and validation close to submission. The project describes the desired shot. The selected adapter exposes only the controls that the current route supports, compiles a preview of the real request, and rejects invalid combinations before money is spent.

This also creates a clean relationship with agentic systems. An AI coordinator can help assemble context, request specialist reviews, compare options, and record recommendations. It should not be the hidden transport layer on which every provider call depends. The studio should own its records and integration boundaries; agents should operate through visible, auditable actions.

Shots, takes, selects, and the path to the edit

A project-first system needs to model filmmaking decisions rather than merely archive outputs. The smallest useful unit is the shot card: subject, action, setting, camera intent, expected duration, linked assets, and explicit pass/fail criteria. A generation is then one attempt at that shot, not the shot itself.

That separation makes iteration intelligible. Several models may attempt the same shot. Some outputs may fail continuity but contain a salvageable reaction. One may be suitable for a demonstration but not a final cut. Another may be selected, then replaced after the edit reveals a pacing problem. The record should preserve those distinctions with simple review states and notes.

From shots and generations, the production moves to selects. Selected video should sit beside the sound work it needs: dialogue stems, voice references, ambience, room tone, Foley, effects, music cues, and mix notes. “No generated music” is a generation constraint, not a declaration that the finished film has no music. Sound deserves a first-class production lane because video providers do not understand the complete editorial plan.

The final internal destination is an edit handoff: stable filenames, clip order or edit-map notes, source provenance, known fixes, sound requirements, and the decisions an editor needs without reconstructing the entire production history. Publishing can remain a separate, explicitly approved stage. The system should help prepare a release package; it should not assume authority to release one.

Visible worker passes and explicit gates

I also want the system to make collaborative AI work less theatrical and more accountable. “AI Director” is an attractive button label, but it hides too much. A production benefits more from named, bounded passes: script polish, continuity review, visual-state checks, shot economy, provider strategy, sound design, edit salvage, and packaging.

Each worker pass should identify its target, role, status, notes, and recommendation. The result is not automatically a decision. It is evidence placed into the project record for reconciliation by the production lead. That keeps specialist input visible without turning the film into a committee of opaque agents.

The same philosophy applies to authority. There should be explicit gates for spending, generation, destructive provider actions, canon changes, and publication. A validated payload is not approval to submit it. A completed worker pass is not permission to alter production files. A selected clip is not permission to publish. Automatic retries are particularly dangerous because a technical convenience can quietly become repeated spending.

These gates are not friction added after the interesting work. They are part of the architecture. They define where human judgement enters the system and make it possible to increase automation later without losing control of cost, continuity, or public output.

Proving the thesis with one vertical slice

The temptation with a studio system is to design the whole studio: screenplay tools, dashboards, asset management, analytics, scheduling, publishing, and a grand multi-agent control room. That would be an effective way to postpone learning whether the central idea is useful.

The first meaningful test is much smaller. Open one project and one shot. Attach a prompt, a start image or reference, and one existing logical Element. Choose between a primary provider and one verified alternative. Show only supported controls. Preview and validate the provider payload. On one explicit generate action, submit one job with no automatic retry. Poll it, download it, preserve it under the project, and mark the take as passed, reroll, or selected.

If that slice can switch engines without losing the shot’s intent, assets, provenance, or review history, the architecture has earned another feature. If it cannot, a broader interface would only conceal the failure.

That is the standard I am using for Nodupon’s Project-First Cinema Studio. The goal is not to build another place to type prompts. It is to give the film a durable centre of gravity—one that survives changing models, changing providers, and the messy sequence of choices by which a generation becomes a shot and a collection of shots becomes a finished work.