Storyspan 源映

Product positioning

The product of Storyspan (源映) is the screenplay: a screenplay that can be handed to someone else and accepted by them, carrying complete delivery records — which version, who approved it, when it was locked, and the file fingerprint.

The finished film is the creator's own work and stays an internal output. The film-output stage therefore keeps only its thinnest layer: hand the frozen prompt package to one external executor, get back a playable file, and keep one run ledger. The prompt package itself is an internal artifact — viewable, freezable, exportable, and hand-carryable to any external tool — not priced separately and making no picture-quality promises. This division keeps the product's promises tied to what it can deliver for acceptance.

Knowledge with a version number

Extraction only runs inside a declared framework, and every framework carries a version number. When a framework is revised, old extracted atoms keep their old version; nothing already accepted is rewritten in hindsight. That rule keeps knowledge auditable long after the fact: any statement in the system can be traced back to the framework version and the source material it rests on.

Six knowledge angles are live — writing, scene, directing, props, continuity, and generation constraints. Coverage of each angle's own frameworks is an on-demand breadth item, not a completed angle-by-framework matrix.

A real drill put numbers on the boundary: 269 paragraphs of a textbook produced 19 candidates, each reviewed one by one under the owner's delegation — 9 adopted, 10 rejected. Adopted items were rewritten by hand before promotion. When a later review finds an extraction wrong, the error can be marked and the works in progress that depend on it get alerted.

The screenplay as the product

The story trunk is the single source, entered three ways with equal standing: an original concept, an adaptation with clear rights, or knowledge-assisted assembly from the extraction module. One trunk can carry several adaptation contracts — a single film or an episodic series — and choices like aspect ratio, visual style, language, and release versions live at the production-version layer under each contract.

Character, relationship, and scene bibles take shape from actual usage; a short film gets a bible that is narrower, not shallower. Scene revisions carry per-item approval as recorded semantics, and the three checks — change impact, continuity, script doctor — run at the outline, scene, and lock gates on an acknowledged baseline with incremental projections. A blocking finding is advisory and does not stop a lock.

After a lock, the system issues a formal release record and the screenplay exports to Fountain. Start the project, write the scenes, run the checks, approve the lock, export — that main chain is wired end to end.

Compile, do not translate

This module is called generation preparation and compilation because it does not paraphrase a screenplay into prose for a model. It compiles: an approved screenplay becomes storyboard and reference bindings, then a model-neutral generation contract, and finally an artifact written in one target model's official format specification. The frozen prompt package is an internal artifact — the handoff format for an external executor — not a product on its own.

When a screenplay asks for something the compile target cannot express, compilation refuses and reports the capability gap explicitly instead of silently dropping the request. That fail-closed behavior has been delivered.

Quality conclusions use a three-level vocabulary: format-legal, server-accepted, and generation-quality-verified. The system presents the conclusion and never adjudicates it for the creator; until a real executor is connected, it can give at most the first level.

Every frozen package pins its target model, format specification, and compiler version. Any change upstream — screenplay, storyboards, reference assets, or compiler — marks that package stale instead of silently rewriting it.

Compile targets are many; execution targets are one. A format with no attached executor is marked manual-export-only, so the boundary of what can actually run stays visible.

How it is built

Architecture first, then code. The product architecture is an 89-item charter, each item voted on line by line by the creator and the design side, then handed to independent review for repeated challenge until it froze without dispute; every resolution keeps its reason on record, and every later feature can be traced back to the resolution it rests on.

Delivery proceeds by feature packages: the ones that settle the data shape go first, in order, and extensibility features are pulled on demand. Every package passes three gates — design review, implementation review, and final acceptance — before it merges, with no exception among the 48 packages.

The division of labour is explicit: design, independent review, and implementation each do their own part, and the creator holds final adjudication. All records are append-only and never overwritten, so how this product was built, step by step, is itself auditable.