01
Project storage
Persistent project state tracks beats, source paths, generated outputs, approvals and stale dependencies.
Models help. Project state stays in charge.
The system is designed so AI providers perform bounded jobs inside a persistent production model rather than becoming the owner of that model.
Architecture
A local-first production core with replaceable model capabilities.
The design goal is to keep project files, approvals and production state durable while allowing model providers and generation tools to evolve independently.
02
Capability adapters
Language, narration, transcription and media-generation capabilities are treated as replaceable providers behind explicit interfaces.
03
QC & revision layer
Outputs are validated against the project model before they are accepted as current production state.
04
Asset layer
Source media and generated assets remain addressable as files rather than being trapped inside opaque generations.
05
Timeline assembly
Beat timing and asset mapping become structured timeline segments suitable for downstream editing.
06
Human approval
Model output can accelerate the workflow, but approved project state remains inspectable and reversible.
Claude roadmap
Reasoning-heavy tasks are where Claude can add the most leverage.
The planned integration is not “send the whole project to a chatbot.” It is a set of explicit, reviewable capabilities with structured inputs and outputs.
| Capability | Planned use | Product constraint |
|---|---|---|
| Long-context script analysis | Read a complete script, identify semantic beats, continuity risks and production dependencies. | Suggestions do not silently replace the source script. |
| Structured beat planning | Propose beat boundaries, visual responsibilities and production notes in a schema the app can validate. | One beat remains one visual responsibility in the project model. |
| Consistency / QA | Check script, narration, subtitles and visual plans for contradictions or missing coverage. | QA produces findings; approval remains explicit. |
| Revision reasoning | When the script changes, propose which dependent outputs should be considered stale and why. | The application decides state transitions from validated rules. |
| Production assistance | Draft structured prompts, shot descriptions and asset-search terms from approved beat intent. | Generated instructions remain attached to the beat that produced them. |
Why this architecture
Model quality can improve without rewriting the product’s rules.
A production application needs durable state, repeatability and revision history. Keeping Claude behind explicit capabilities makes it possible to benefit from stronger models while preserving predictable project behavior.
Privacy direction
Local files by default. External AI calls only when a capability actually needs them.
Current engineering focus
Reliability before breadth
The product is being developed around repeatable project storage, targeted regeneration, timing correctness and editable handoff before attempting to automate every creative step.
Provider independence
Model services are useful capabilities, not the product database. That separation reduces lock-in and keeps project state understandable when providers change.