Story Source Language — primary-source research

Research date: 4 November 2026. This is design input for the proposed language, not a claim that Studio implements it. The recommendations below are our design judgments; the linked specifications establish the external facts. The scope is selected, relevant precedents, not an exhaustive novelty search.

1. Start with meaning, then define concrete notation

A language specification needs independently understandable layers: the domain concepts, their invariants, the permitted textual representation, the effect of each operation, and the observable behavior required of an implementation. A grammar alone cannot establish who may approve a story choice or what a revision does to a citation.

ABNF is an established notation for formal syntax. Its operators describe alternatives, sequences, repetition and value ranges. It also separates terminal values from their external encoding. A practical trap is that quoted ABNF strings are case-insensitive by default; a specification using a different grammar notation must define its conventions instead of loosely calling it ABNF. RFC 5234, §§2–3

Recommendation: Define the abstract story model first; provide one exact grammar and its encoding rules; distinguish parse errors, model violations, authority failures and craft findings. State the meaning of uppercase MUST/SHOULD/MAY consistently with BCP 14. That convention gives uppercase words their normative meaning; ordinary lowercase prose is unaffected. RFC 8174

2. Fountain is an expression format worth preserving

Fountain recognizes screenplay elements using readable conventions, with explicit forcing syntax where needed. It supports dialogue, dual dialogue, action, headings, transitions, lyrics, emphasis and title pages. Notes, sections, synopses and boneyard text have special behavior; in particular, some source material is omitted from formatted output. Its action rules preserve intentional line breaks. Fountain syntax

Recommendation: Keep a complete Fountain body as literal, versioned expression. Do not encode critical story choices or approval records inside Fountain comments and expect ordinary Fountain tools to preserve their meaning. Plain Fountain export is a screenplay projection; it cannot, by itself, be the lossless export of a story's memory, sources, variants and operation history. Preserve raw source separately from its parsed rendering tree. A parent story language should define its own boundary around the payload so screenplay punctuation cannot accidentally become an instruction.

3. Ink demonstrates a different, useful narrative-language design

Ink combines authored text with choices, named knots and stitches, diverts, variables, conditional content, functions and flow control. Its documentation explains that the resulting story can react to state and choices. Variables and functions have runtime semantics, including some forms of game-side integration. Writing with ink

Recommendation: Borrow the idea of stable, addressable narrative units and progressive introduction of structure. Keep authoring alternatives distinct from reader-playable branches. A draft ending under consideration should not become a runtime condition by accident. For Studio's initial language, deterministic rendering of selected authored material is sufficient; executable story logic would require a separately specified profile. This is a scope choice, not a finding that Ink is unsuitable for its own intended use.

4. Provenance describes derivation; authority needs additional rules

W3C PROV-DM distinguishes entities, activities and agents, and describes derivation, attribution and responsibility. Its bundle mechanism also supports provenance about provenance. The model is domain-independent and extensible. PROV-DM

Recommendation: Model source passages, agent findings and writer decisions as separate things. Record the source revision an activity used and the revision it produced. A claim that an agent attributed material to a writer is still a claim until the host verifies the relevant source or decision receipt. Provenance links alone must not grant editing permissions, establish fictional truth, or promote a suggestion to an accepted choice. Preserve failed or superseded derivations without letting them override current choices. Describe any PROV export as a mapping, not conformance merely because similar nouns appear.

5. Anchors need a particular representation of the text

The Web Annotation model provides text-quote selectors, text-position selectors and representation state. It explicitly warns that positions are brittle when a resource changes, and recommends identifying the relevant representation. Its text-selector normalization rules are part of that model. Web Annotation, selectors

Recommendation: Anchor exact evidence to object identity, immutable revision, field and explicitly defined offsets; include the expected quote or digest. Define whether offsets count UTF-8 bytes, Unicode scalar values or UTF-16 units. Do not silently use a language runtime's string length. If the language requires preservation of original code points, specify its own exact-text selector and a documented Web Annotation mapping rather than claiming identical selector semantics. Re-anchoring to a later revision must produce an explicit result; ambiguous matches remain unresolved.

6. Canonicalization is a hashing contract, not permission to rewrite prose

JSON Canonicalization Scheme uses deterministic property ordering and serialization, with constraints on values. It prohibits duplicate object properties, relies on interoperable numeric representation, and requires parsed Unicode string data to remain unchanged. It does not apply Unicode normalization. JCS is an informational RFC. RFC 8785, §§3.1–3.2

Recommendation: If canonical JSON is used for digests, explicitly adopt its restrictions and identify the hashed object fields. Preserve expression strings exactly; normalize neither typography nor Unicode composition during hashing. Keep lexical source-file identity separate from semantic-model identity: changing indentation outside a literal may alter a file hash without altering the model hash. A hash establishes content identity, not authorship or permission. Long revision counters or exact quantities should use a representation that survives all supported runtimes.

7. JSON is useful transport, but its permissiveness needs a profile

JSON object member order has no semantic significance; arrays are ordered. The JSON RFC recommends unique member names and describes interoperability problems when duplicate keys or numbers beyond common implementation precision are used. It requires UTF-8 for exchange outside closed ecosystems. RFC 8259, §§4, 6, 8

Recommendation: For a JSON interchange profile, reject duplicates before normal object construction, use a bounded numeric domain, and reserve ordered arrays for meaningful order. Store scene identities independently of their array positions. The grammar for any more readable authoring syntax must map unambiguously onto this model; JSON serialization and pretty-printing must never be confused with preservation of the original source bytes.

8. Patches need application-level concurrency and recovery

JSON Patch defines ordered operations such as add, remove, replace, move, copy and test over a JSON document. Unsuccessful evaluation is not a successful patch; its HTTP PATCH discussion relies on atomic application. Array indexes have positional meaning, which can change as preceding operations execute. RFC 6902, §§4–5

Recommendation: Use domain operations addressed by stable IDs and explicit expected revisions, even if their implementation uses a patch internally. Apply a submitted change atomically; preserve account, story, operation identity and payload digest. Retrying a timeout must recover the original receipt before creating another mutation. JSON Patch alone does not supply authorization, idempotency, story-specific Undo, or approval rules. A generic replace operation must not be able to manufacture an approval or rewrite the provenance ledger.

9. Extensibility requires an honest compatibility contract

JSON Schema distinguishes a schema's structural constraints from vocabularies defining keyword syntax and semantics. Its vocabulary mechanism can require an implementation to understand a vocabulary or refuse processing. Unknown individual keywords can otherwise be treated as annotations. It cautions against combining conflicting vocabularies. JSON Schema 2020-12 Core, §§4.3.3, 8.1, Appendix D

Recommendation: Pin the immutable core version and preserve namespaced definitions and unknown fields as data. Let agents introduce new concepts immediately, with generic readable rendering and advisory schemas; later formalization should not be a prerequisite for saving an idea. Refuse an unsupported requested effect, rather than refusing to store or inspect its description. A valid schema does not prove referential integrity, writer authorization or meaningful drama. A new definition may describe a desired operation, but must not grant itself execution privileges or change the meaning of core identity, authority or exact text. JSON Schema supplies a precedent for separating annotations and assertions; the proposed language chooses its own more permissive authoring policy.

Design conclusions for the specification

These are proposed synthesis decisions rather than claims made by the sources:

1. Use an open declarative record model: namespaced concepts and generic values can be introduced without a global ontology change. Use a declarative core that stores authored material and explicit relationships. Rendering selected prose should require neither model inference nor arbitrary code execution.
2. Give identity, revision, source, scope and status explicit semantics. Distinguish an object's identity from a particular revision and from its position in a sequence.
3. Separate fictional events, presentation order, character belief, audience exposure and an agent's interpretation. Their agreement is not automatic.
4. Let fragments and unresolved questions be valid states. A missing claim is unknown, not false; a valid document need not be a finished story.
5. Preserve exact expression and its history. Interpretations can be revised without silently altering the words they interpret.
6. Treat writer decisions and host receipts as controlled events. A text field spelling “accepted” cannot grant itself authority.
7. Specify both lossless exchange and intentionally reduced projections. A screenplay export should state what it leaves out.
8. Make conformance executable through positive and negative fixtures: invented concepts round-trip without registration, unknown concepts render generically, advisory schema failures preserve drafts, unsupported effects produce an explicit capability result, Unicode boundaries, literal delimiters, unknown extensions, stale citations, partial snapshots, concurrent edits, duplicate operations, alternative versions and export loss reporting.
9. Validate agent usefulness experimentally. These sources do not establish that a new syntax makes models better storytellers or that this design is unprecedented.

The next engineering proof should be a parser/model round trip and an independent validator over small synthetic fixtures, followed by read-only export from the existing owners. Migration becomes justified only after identity, exact text, decisions, history and recovery survive the comparison.

10. Queryability and computation need explicit semantics

SPARQL 1.1 is a useful reference for graph query design: it specifies graph patterns, filters, optional matches, named graphs, aggregates, property paths and solution modifiers. Its query language specification is distinct from update and protocol specifications. SPARQL 1.1 Query Language

Recommendation: The story language may expose its own small typed query algebra without requiring RDF storage or SPARQL syntax. State which snapshot, branch, accepted/proposed statuses and visibility scope a query uses. Return a completeness indicator with results; no rows in a partial snapshot cannot establish that something never occurs. Define missing versus explicit null, equality across references, sorting, pagination, aggregate behavior and bounded graph traversal. Derived results should record their expression, inputs and evaluator version. Recomputing a count or duration is deterministic computation; deciding whether a scene is moving remains an attributed judgment. Querying a novel agent-defined kind should work immediately as generic data. A new computation operator requires a supported evaluator before it can run, while its description can still be saved.

11. OTIO supplies an editorial interchange boundary

OTIO's timeline model includes tracks, stacks, clips, gaps and transitions. Its time-range documentation distinguishes ranges in a clip's own media coordinates from ranges in its parent; trims and transitions change which ranges are relevant. Available media duration can be unknown, and intentional requested ranges can extend beyond available media. Timeline structure, time ranges

Recommendation: A postproduction profile should link to versioned OTIO artifacts and map clip-instance identity, selected media version, track placement, source range, transitions and supported retiming. Keep the screenplay order, shooting schedule and editorial sequence separate. The same story scene may have many takes and several appearances in an edit. A new cut must not silently reorder the screenplay. An incomplete edit can remain valid authoring material while export or conform reports missing media/handles.

OTIO provides native JSON and media-bundle adapters, with additional formats available through plugins whose support levels vary. OTIO adapters

Recommendation: Pin adapter versions and publish a feature/loss report for each transfer. A listed AAF, XML or EDL adapter is not proof that every effect, source identity, marker or piece of metadata survives round trip.

12. Time needs a rate, a coordinate system and an interval convention

OpenTime represents a time as value divided by rate, offers rescaling, and distinguishes inclusive from exclusive range ends. Its Python API exposes floating-point-compatible value/rate arguments. OpenTime API

OTIO's reference implementation handles drop-frame timecode separately from its rate and recognizes exact fractional expressions such as 30000/1001 alongside common decimal rate inputs. OTIO RationalTime implementation

Recommendation: Store rational rates explicitly as numerator/denominator, an integer sample/frame index where appropriate, and an explicit coordinate domain. Use half-open ranges in the language profile and define adapter conversion. Distinguish media rate, displayed timecode, audio sample rate, presentation timestamps and wall-clock shoot timestamps. Drop-frame is a timecode-label convention; it must not instruct the system to remove media frames. Preserve source timecode and its drop-frame flag; do not infer the flag from a rounded decimal rate. Converting rates needs an explicit rounding policy and precision/loss result. Variable-frame-rate material needs a timestamp mapping rather than an invented constant frame rate. Timecode does not uniquely identify a media file or a date.

13. OpenUSD provides composed scene description, not story identity

OpenUSD provides layered composition, references, variants, typed properties and relationships for scene description. Its introduction explicitly notes that it uses hierarchical namespace paths rather than GUID-based identification, and namespace edits can invalidate previously authored overrides. OpenUSD introduction

USD's linear-unit encoding is stage-wide, using meters per unit. Assembling differently scaled assets requires corrective transformations; reading an arbitrary local transform as an absolute world-space distance is unreliable. Encoding stage linear units

Recommendation: Reference a versioned USD asset and its composition configuration instead of copying geometry into story records. Keep the language's stable asset ID distinct from a USD prim path and a filesystem locator. Record the selected variants, resolver context and layer dependencies needed to reproduce a result. State units and coordinate conventions explicitly at the integration boundary. Do not assume that changing a narrative location changes a production set, or that renaming a character safely renames every associated USD prim. Mapping and namespace repair are explicit operations with receipts.

14. MovieLabs already defines a broad media-creation vocabulary

MovieLabs' OMC documentation covers context, assets, participants, tasks, creative works, relationships and infrastructure. It includes camera, audio, CG and image-related material. MovieLabs OMC documentation

Its Context specification distinguishes narrative concepts from their production counterparts. A generic narrative object can be refined when its production role becomes clearer, and its sample attributes include identifiers, descriptions and custom data. OMC Context v2.8, narrative and production objects

Recommendation: Build an explicit mapping profile to selected, version-pinned OMC terms. Keep a fictional person, performer, performance, take and media asset distinct. Likewise distinguish a fictional object from the physical or CG props depicting it. Use relationships to connect them, with production-specific context. Start with coarse concepts and permit later refinement; mapping to an industry term should not be mandatory before an agent can save an idea. Do not claim OMC conformance from similar field names alone, and do not claim novelty for having a shared vocabulary across filmmaking.

15. Proposed production profiles and asset evidence

The following is our proposed architecture, not a statement that the cited standards jointly implement it or that Studio currently supports production:

• Preproduction records can describe breakdown needs, shot intentions, boards, cast, locations, resources, schedule assumptions, estimates and approvals. They should cite the screenplay revision from which they were derived. A scheduling assumption is distinguishable from a booking or commitment.
• Production records can connect shooting days, units, slates, takes, camera/audio captures, continuity notes, actual usage and incidents. Narrative intent and what was captured may disagree without destroying either record.
• Postproduction records can connect edits, media selections, VFX work, sound work, grades, subtitles, reviews and deliverables to their source assets and revisions. A delivered artifact needs its own content identity, format description and completion receipt.
• An asset should distinguish stable logical identity, immutable version, byte digest where applicable, byte length, media type, source/provenance, storage locators and access policy. A path is a locator, not proof of content; a digest identifies bytes, not rights or authorship. A directory, sequence or composed asset needs a manifest of its dependencies.
• Queries should cross these relationships: which approved script passages still lack coverage; which shots use an obsolete prop version; which edits depend on a replaced take; what a delivery includes. An impact result must expose incomplete mappings rather than imply comprehensive coverage.

These profiles allow an industry-facing ambition while keeping the core open and small. Each integration still needs domain review, representative interchange fixtures and real-tool qualification before claiming operational readiness.