Standard vocabulary and lifecycle profiles

1. Open library, precise opt-in contracts

The following terms are the proposed standard library. A record can use any term with partial fields and still be stored, read and queried. This document defines intended meaning and interoperable field shapes. A producer advertising a profile MUST use those meanings and shapes for the fields it supplies. A profile-specific operation can require the fields necessary for that operation; it cannot require the entire work to be complete.

Notation: T text, B boolean, I integer, D exact decimal, R rational, Ref<K> reference to the indicated kind, Exact<K> exact reference, [] ordered array, Map open object of Values, Anchor language §5. Unless explicitly stated all fields are optional; title:T, notes:T, sources:Anchor[], derivedFrom:Exact[] and dependsOn:Ref[] are available on EVERY record. A display label or notes field is never evidence of authority. Natural-language fields are never silently parsed into asserted structure.

Table fields use name:Type; alternative kinds use |. Definitions may describe additional properties. A matching kind is checked by expanded namespace identity. Fields with undeclared specialised meanings survive as open data. Profile validation returns field-level findings (missing-for-operation, type-mismatch, unresolved, unsupported), not rejection of the whole story.

2. Core library

Assets are metadata and references. Large video/audio/binary payloads remain outside JSON. The same bytes can have different rights/access contexts; content identity never implies permission. Different transcoded/proxy representations have different hashes and explicit links to their source.

3. Story and memory

story.claim.mode standard values: world, belief, utterance, interpretation, research, intention. stance: asserted, denied, uncertain. Missing mode/stance means unspecified, never world/asserted. modality independently carries possible, conditional, counterfactual, obligation or reported; it is not collapsed into mode. Context effects are explicit include/exclude/replace entries over exact refs, preserved as data unless a selected context evaluator defines their composition; no implicit inheritance inference. A computable triple requires subject, predicate and object together; a prose-only proposition is valid. To infer a contradiction, the predicate definition must specify exclusivity and value comparison; open properties are not assumed single-valued.

Story acceptance is orthogonal to claim stance. A host-confirmed choice can select a claim about a belief or denial. Profile queries for settled story material follow valid choices/receipts and context, never a mutable label alone. Prototype imports may mark historical authority unverified while preserving the original evidence.

Temporal relation terms include before, after, overlaps, simultaneous and unknown. Explicit time can be an expression ("three winters later"), a rational interval relative to a named story clock, or a sourced calendar representation. Without a shared clock, numerical comparison is unknown. A causal link is a claim, not inferred from temporal adjacency. Cyclic before constraints create a finding; a fictional time loop can use distinct context/clock semantics and remain represented.

4. Narrative and screenplay

An edition's order is authoritative for that edition. Do not independently sort by scene number or filename. Resolve an edition order left to right. A direct occurrence emits that occurrence. A beat expands its sceneOccurrences in stored array order; a missing or empty list emits a labelled beat placeholder (missing also reports unresolved). No recursive beat nesting is implied. An occurrence appearing more than once in the flattened order produces duplicate-occurrence and blocks a frozen export claiming conformance; repeat presentation instead creates a new occurrence referencing the same scene/event. Draft selection is explicit and exact. Missing drafts become labelled placeholders in a development reading. A delivery operation may require all entries resolved, but an unfinished edition remains valid.

The proposed Studio profile derives this order from its existing Outline owner; it does not create a second editable order. Script reading pins a snapshot. A frozen edition/export additionally records the complete exact-reference closure of every traversed beat, occurrence, draft and expression, so a later head cannot change an older export. Inserting/omitting unwritten placeholders is an explicit export option, recorded in the export receipt.

Fountain adapter requirements: pin parser/dialect; retain full body and original source assets when available; preserve title page, action, dialogue, parentheticals, dual dialogue, transitions, lyrics, emphasis, sections, synopses, notes and omitted/boneyard material. Structured views are derived. Unsupported syntax is shown literally and included in a loss report; it cannot disappear silently. Scene numbers are labels, and Fountain names are text, not automatic person identity. A parsing suggestion to link a character requires disambiguation when names collide.

5. Shared production value contracts

These contracts are normative when a producer advertises production-values/0.1. Partial/informal values remain valid open data but fail a dependent precision check.

• Money: {"amount":{"$decimal":"1250.5"},"currency":"INR"}. Three-letter currency code is a label; conversions require explicit dated rates and sources. Different currencies cannot be summed implicitly.
• Quantity: a Decimal or Rational with a declared unit. Dimensions and conversion factors must be supplied by the selected unit registry. day is not implicitly 24 shooting hours.
• Instant: {"utc":"2026-11-04T03:30:00Z","zone":"Asia/Kolkata"} with optional original local form and declared timezone database version. UTC identifies the instant; zone supports display. Unknown local dates remain text; nonexistent/ambiguous local times need resolution before scheduling.
• Media time: {"frames":I,"rate":{"$rational":[24000,1001],"unit":"frames/second"}}. Frames are integer frame/tick positions on a declared asset or timeline clock. A MediaTime may include clock:Ref; when absent it inherits the unambiguous owning recording/asset for source time or edit for timeline time. If that context is missing, comparison returns unknown. Equal rates do not make different clocks comparable; explicit sync mappings are required. Rate MUST be positive. A range is {start:MediaTime,duration:MediaTime} using the same rate/clock, duration nonnegative, interval half-open.
• Timecode: {label:T,nominalFps:I,dropFrame:B,rate:R,origin:MediaTime}. The label is display notation, not time itself. Portable drop-frame conversion supports only 30000/1001 at nominal 30 skipping labels 00–01 at second 00 of every minute not divisible by 10, or 60000/1001 at nominal 60 skipping labels 00–03 at those boundaries; other combinations require a declared profile. Labels use HH:MM:SS;FF for drop-frame, HH:MM:SS:FF otherwise, HH 00–23, MM/SS 00–59 and FF below nominalFps. Parsing skipped labels is invalid. No frames are physically dropped. Day rollover requires an explicit integer dayOffset. Unsupported label conversions preserve the label and return unsupported.
• Geometry: {system:T,unit:T,value:[D,D] | [D,D,D]}; right/left handedness and axis conventions belong to system definition. An unknown coordinate system prevents transformation, not storage.

6. Pre-production profile

Pre-production computations include declared breakdown counts, affected departments after draft changes, resource overlaps over comparable instants, budget totals in a specified scenario/currency and missing permissions. Extracted breakdowns name the draft and evidence; a script revision makes them stale. No parser can guarantee every practical requirement was inferred from prose. A schedule solver is a versioned capability taking explicit constraints and returning a proposal plus feasibility status.

7. Production profile

A shot can cover several screenplay occurrences; one occurrence can have many shots. Multiple cameras can produce recordings for the same take. Media filenames/slates can collide and are never IDs. A production event that happened on set is distinct from the fictional event being portrayed. Metadata supplied by devices retains original representations and parser versions.

8. Post-production profile

The portable media-time contract assumes constant frame rate. Variable-frame-rate media retains a presentation-timestamp mapping in an extension/asset; precise operations require an advertised evaluator and otherwise return unsupported.

A portable editorial calculation requires edit rate/origin, each clip's source/timeline ranges and understood speed mapping. At speed 1, source duration in seconds equals timeline duration in seconds, even if source and edit rates differ. Constant speed maps sourceTime = sourceStart + (timelineTime - timelineStart) × speed, with all terms expressed in exact seconds after rate conversion and mapped clocks; negative speed is allowed with an explicit supported profile, zero speed means freeze and needs an explicit source frame. Variable speed curves are opaque extensions until a versioned evaluator is selected. Unknown effects can remain in the edit but an output claiming fully rendered effects must fail its readiness check.

Track ordering uses explicit timeline ranges; array order breaks identical-start ordering only. Overlap without a declared composite/transition is a finding, not an arbitrary clip deletion. Interchange adapters must distinguish source time from parent/timeline time and nested compositions. Media duration, source handles, sample/frame grids and missing assets need validation before rendering. Exact media specifications such as codec, channel labels and colour transforms should bind external standards/profiles rather than invent incompatible synonyms.

9. Delivery profile

A delivery manifest pins exact edit/edition, source snapshot, complete transitive exact-reference closure of composition records, asset digests, selected profiles, renderer/adapter versions and known loss. A root exact reference alone does not freeze live child refs. Working compositions may use snapshot refs; historical reproduction uses the recorded closure and snapshot, never current heads. Missing closure/assets prevents a claim of complete reproducibility. A delivery can be described before all dependencies are present. Publishing or asserting delivery completeness requires the chosen specification's checks and an authorised effect receipt. Rights, labour, financial and safety decisions remain professional/human responsibilities; SSL records evidence and constraints rather than declaring compliance from a label.

10. Interoperability contracts

Every adapter result identifies source format/version, adapter version, original byte digest, resulting snapshot, mapping of identities and preserved opaque payloads. Loss reports list exact affected fields/assets and severity. An export that cannot preserve extension data must either attach a lossless SSL sidecar or explicitly report it; it must never advertise complete round-trip fidelity. Sidecars cannot be required by tools that do not support them, so recipient capability is checked.

The goal is a shared language across departments with practical interchange, not a claim that all department semantics are solved by these first-cut terms. Extensions are the intended route for concepts uncovered through actual use.

11. Doctrine profile

Namespace prefix doctrine → urn:ssl:0.1:doctrine. The writer's doctrine (the craft rules that bind their screenplays) as records, so queries can join rules with scenes, drafts, claims and findings. These records are a host-derived projection of the story's active doctrine (projectDoctrine in packages/screenplay/src/story-source/doctrine.ts); writes to the doctrine go only through the writer's own words, never through SSL-P. See doctrine in SSL.

Identities are deterministic within projection generation 2: a rule is urn:screenplay-company:doctrine:v2:rule:<origin>:<encoded rule id> at its semantic revision (existing writer rules begin at 1; default rules use the published version). Checks and sets also use the doctrine:v2: prefix. A check identity includes the doctrine evaluator version and uses its rule revision. A set identity includes the story slug and active doctrine digest, at revision 1. Older unversioned references remain untouched; their findings are displayed as stale history and cannot count toward current coverage. Native read receipt identities include the generation so a new reading cannot replay an older finding's receipt. Membership, current order, applicability and effective parent bindings live in the immutable set, so renaming a selected screenplay or reordering rules cannot change an exact rule record. Writers change rules only through the doctrine owner; SSL imports cannot grant account policy authority.

The built-in computed checks use expectation:"none" and return one row per violation; the row's record and exact-reference cells become the finding's targets, a reason text cell its explanation and a quote text cell its evidence. A custom check may declare none, all-true or nonempty and is evaluated according to that expectation. A judged finding is an attributed reading by a doctrine reader, stored by the host, never writer canon. It is stale once the rule revision changes or any target is no longer at the exact state it read (absent from the snapshot, or at a different revision): stale findings are listed but do not count. A rule's status rolls up its current findings: followed (all current findings pass and required material is covered), broken (any fail), mixed (some pass, with unknown or unread material), unknown (the data cannot decide) or unchecked (no current finding). Unknown and unchecked never count as followed.

Judged findings target exact states. In the Studio work projection, scenes, drafts, specs and beats keep stable identities across reads, and their revisions change only when their projected state does, so a finding stays fresh until what it read changes.

Doctrine reports expose coverage.required, read, unchecked and complete per rule. A new relevant record requires a reading; one passing example does not establish the whole story. Computed checks describe only what their exact query proves. A complete custom query does not establish that every scene was individually examined. Whole-story and outline judgments bind their complete creative basis. Scope, unsupported data and bounded evaluation limits remain explicit.