SSL 0.1 desktop implementation

The shared language runtime, durable record protocol, current Studio owner adapters, full-work archive/migration, lifecycle profiles and named interchange adapters are implemented in source. The desktop consumes them through one story-bound application service. This document describes that implementation; the verification record distinguishes passing source tests from release, installed-app and external production qualification.

The authoring database remains authoritative. SSL is its portable record language and operation protocol. Existing stories acquire a lossless projection without a destructive storage rewrite. Human writing surfaces continue to show text. Web UI remains deferred as requested.

Shared runtime

Import @screenplay-company/screenplay/story-source. The runtime uses TypeScript and Web Crypto, with no UI, network, filesystem, model-provider or downloaded-code dependency.

packages/screenplay/reference/ssl_core.py is an independent standard-library Python core reader/writer. It exchanges fixtures and canonical digests with TypeScript. reference/exact_arithmetic.py is an independent Fraction oracle for numeric/time differential tests; it does not claim a second complete SSL-Q implementation.

Core portable bounds are 10 MiB per document, 1 MiB per string, 10,000 records, depth 32 and 1,000,000 values. Each evaluator publishes additional limits. Exhaustion is explicit; it cannot become a complete empty answer. Unknown concepts remain writable data; unknown effects cannot become executable code or host authority.

Durable record owner

apps/api/src/lib/story-source.ts executes SSL-P through the existing native story transaction. Immutable native material revisions carry the exact logical record in body.languageRecord. Large payloads use immutable content fragments in the same atomic transaction. A reserved manifest retains namespaces and unknown top-level metadata; an operation envelope retains the exact original proposal. Internal fragments/manifests/requests are excluded from ordinary human material queries/search, while exact history and archives retain them.

Logical IDs and kinds stay unchanged. Physical owner IDs are deterministic hashes when necessary, with the full original identity in the envelope and receipt. A logical revision uses its owning native revision, including Undo/tombstone/restore history. This is one authority, not two independently written story stores.

The owner validates the original base, target expectations, exact read dependencies, namespace bindings and optional whole-snapshot guard. All changes and the original request digest commit together. A failed member rejects the entire batch. A retry with the same operation and digest returns its original receipt; changed content under the same operation is a conflict. Disjoint changes can proceed only after revalidation against a definitive owner conflict. An uncertain network outcome is never silently rebased.

Contributions retain proposed agent provenance and cannot overwrite writer-managed records. Writer changes require the current signed source and exact quote. Data fields saying “writer”, “approved” or “cleared” confer no authority. Generic Undo routes through the language owner so later declared dependencies are checked before the native compensating transaction.

Current Studio authoring

studio.authoring/0.1 dispatches to the existing scene, outline, coverage and memory owners. Its command describes one atomic owner operation. A cross-owner batch is not partially applied: callers must use separate admitted operations or an explicitly supported atomic scope.

Scene operations include starting a scene, revising its spec, writing/checking drafts, selecting a draft, notes/rankings/verdicts and revision notes. Outline exposes its existing typed operation catalogue; memory exposes its established writer-change contract. Coverage pins the actual ordered script basis and selected drafts. Existing scene changes require their spec/selection basis; outline changes require their revision. These are the same implementations used by existing controls.

The host injects attribution and checks the full original signed source. The complete canonical language command, digest and actual owner receipt are recorded in the same transaction as the underlying change. The existing owner's defaults do not alter the digest of the original command. A command cannot supply its own host actor, source, run or operation identity.

Desktop contract

DiscoveryStorySource belongs to the selected account/story session and is used by both application callers and view_operation:

view_operation({
  action: "story-source",
  requestJson: JSON.stringify({ op: "capabilities" })
});

Read contracts:

{"op":"read","scope":"work"}
{"op":"read","scope":"records"}
{"op":"read","scope":"memory"}
{"op":"read","scope":"script"}
{"op":"query","query":{"language":"ssl-q/0.1","snapshot":"RETURNED_SNAPSHOT","from":{"as":"item"},"steps":[{"op":"group","keys":{},"aggregates":{"count":{"fn":"count"}}}]}}
{"op":"serialize","snapshot":"RETURNED_SNAPSHOT"}

work reads one coherent database transaction across current owners and returns their language projection. records reads authoritative generic language records and history. memory and script retain the earlier bounded compatibility projections. Every result declares its actual coverage. A complete selected-state projection is not a claim that every media byte is downloaded. Large archives use the separate paged transfer contract.

calculate, check, view, validate, render, expand, freeze, anchor and readiness operate on retained session snapshots. Computed and display output is separate from authored material. File interchange uses {"op":"interchange","request":{...}}, with an optional retained snapshot for export. The named adapter returns a preview, exact byte encoding and explicit fidelity/loss information; it does not save, render a film, distribute media or grant rights.

Durable owner commands use these envelopes; each owner's capabilities response supplies its exact schema and limits:

{"op":"records","request":{"op":"capabilities"}}
{"op":"records","request":{"op":"apply","proposal":{"language":"ssl-p/0.1","operationId":"urn:example:change:1","work":"RETURNED_WORK","baseSnapshot":"RETURNED_RECORDS_SNAPSHOT","expects":{"urn:example:idea:1":null},"reads":[],"intent":"Retain this possibility","changes":[{"op":"create","id":"urn:example:idea:1","kind":"story.fragment","fields":{"text":"An unfinished possibility"}}]}}}
{"op":"author","request":{"op":"capabilities"}}
{"op":"migration","request":{"op":"capabilities"}}
{"op":"pending"}
{"op":"recover","operationId":"ORIGINAL_OPERATION"}
{"op":"resubmit","operationId":"ORIGINAL_OPERATION"}

Writes require the current signed sourceEventId at the top level of view_operation, outside requestJson. The desktop supplies the full quote and any required run binding. Embedded authority fields are rejected. A dedicated SQLite journal stores the exact signed request before dispatch, with original account/story routing and digests. It has no TTL, LRU eviction or sign-out purge. A full or unavailable journal stops dispatch; a corrupt entry is kept and cannot be retried. recover checks the original owner receipt; resubmit authenticates the current caller, checks the receipt first and resends only the original retained input when absence or an explicitly pending migration is established. A changed/retracted source or changed story can still reject that retry; recovery never manufactures renewed authority. Pending migration responses are not confirmed receipts.

Local draft requests (list, read, save, discard) use the same account/story journal. Save takes a draft ID, exact expected revision (null for creation), base snapshot, canonical base64 of original bytes and linked operation IDs. Invalid UTF-8/JSON and partial streaming output survive restart unchanged; compare-and-swap prevents stale overwrites/discards. These local operational writes require no online writer approval and cannot admit story changes. Raw drafts have a 10 MiB byte bound and share the 128 MiB account recovery budget.

The journal is recovery data, not story authority. Cached reading snapshots are disposable. Native IPC/account checks, request limits and effect classification distinguish read requests from nested owner writes. A request or response belonging to another account/story is rejected.

The background note keeper can also use a narrow SSL read grant: compact work heads, bounded queries, authoritative record/change reads and doctrine reports for its admitted story. It retains the existing background lease, account, current-source and run-budget checks. This grant cannot invoke SSL writes, migrations, navigation or foreground operations. Foreground agents use a compact work head before selecting bounded material rather than fetching the full archive as their default context.

The doctrine integration gives every active rule an immutable semantic revision and a separate story assignment. Desktop views and agents share one coherent owner report with exact findings, current coverage and visible unread/stale material. The writer can ask Home to apply rules to all stories or selected stories; Settings shows those assignments. Existing stories and rules retain their current behavior through an additive database migration.

The earlier top-level apply/reconcile/retry/undo material-expression adapter remains compatible with its original saved operations and recovery. Its twelve-record/text limits remain separate from the generic record owner. Unsupported edits never fall through to an unsafe raw-envelope write.

Existing stories and migration

1. Read the current work directly as SSL. This changes no story content.
2. Capture a signed, immutable full archive. An explicit registry includes current story-owned tables, historical rows, choices, drafts, scene/outline state, conversations and receipts. Newly unclassified schema causes a refusal rather than an incomplete “full” archive.
3. Inspect a dry run. adopt records verified compatibility while preserving current authority and data. restore requires the same stable work/account and an empty target shell. Cross-account or cross-work import uses the explicit two-owner authorization below; it never infers account reassignment.
4. Stage the plan with its source archive, expected current-state digest, backup and operation identity. Apply only the matching still-current plan.
5. Recover the original receipt after interruption. Rollback checks for intervening work and cannot erase later edits.

Cross-work/account import uses three admitted operations, exposed by the same desktop migration envelope:

{"op":"migration","request":{"op":"authorize-import","operationId":"AUTHORIZE_OPERATION","grantId":"GRANT_ID","archiveId":"SOURCE_ARCHIVE","targetWriterId":"EXACT_TARGET_WRITER","targetStoryId":"EXACT_TARGET_STORY"}}
{"op":"migration","request":{"op":"stage-import","operationId":"STAGE_OPERATION","migrationId":"IMPORT_ID","grantId":"GRANT_ID"}}
{"op":"migration","request":{"op":"apply","operationId":"APPLY_OPERATION","migrationId":"IMPORT_ID","expectedPlanDigest":"RETURNED_PLAN_DIGEST"}}

The source owner runs authorize-import on the source story; the target owner runs stage-import and apply on an empty creative target. Each supplies its own current signed writer instruction through the host. Grants bind an exact retained archive, source owner and named target account/story, are not transmitted automatically, and can be withdrawn with revoke-import before consumption. Apply checks authorization, source correction/retraction, owner state, target state and grant consumption in the same transaction.

The fork maps declared physical identities and references, preserves exact original prose and authors, and retains every original row as immutable import evidence. Logical SSL IDs remain unchanged in a new target work with explicit lineage. Imported conversations remain separate historical sources: neither old utterances nor old operation receipts can authorize a fresh destination change. Human and agent authoring continue through the same current owners. Rollback preserves the target's own approval history and refuses to erase newer work.

The atomic import planner has explicit source and rebound archive limits (16 MiB of assembled row data and 16 MiB of verified media). Retaining original-row provenance increases rebound size. Larger source archives remain streamable and readable; imports exceeding the target's declared bound fail before a partial reconstruction is committed.

The archive carries exact original SQL row payloads and schema/identity manifests, plus independently verified asset bytes or explicit missing-media findings. Derived standard records are queryable; source rows preserve fields that have no semantic mapping. Imported execution leases are closed, never reactivated. A file's copied authorship/approval labels are not verification: restore requires the retained authenticated server archive and matching digest.

The existing desktop export action now starts a complete ssl-work/0.1 transfer; old retained export attempts keep their original legacy format. The native exporter checks stream identity, immutable counts/digests, every row and every original media byte before replacing the writer-selected destination. Failure retains a private partial; cancellation captures nothing. The standalone archive reader reconstructs owner JSONL and original binary files only after manifest/stream validation.

Full transfers use bounded row pages and verified asset chunks. Inline work/read responses stay within the published core/transport limits. Original bytes, scalar sequences, immutable drafts, alternative choices, selected readings, anchors and operation receipts remain distinguishable. A schema migration requiring a new adapter fails explicitly; no lossy automatic reinterpretation is performed.

Scope of completion and qualification

The default desktop does not supply professional rights/distribution attestations or a media-rendering engine. Such readiness checks correctly remain unverified until a host integration supplies independently authenticated evidence; authored labels cannot satisfy them.

The implementation covers the executable SSL 0.1 contracts and advertised adapter profiles. It does not implement an artistic judgment engine, universal scheduling solver, USD composition engine, media renderer or legal rights authority: the specification represents those capabilities and requires explicit host/tool support. OTIO effects or foreign metadata that cannot be expressed are preserved with losses/sidecars, not reported as rendered fidelity. Additional FDX/AAF/EDL/FCPXML/subtitle adapter standards remain separately versioned work as specified.

Source tests, real D1/R2 migration tests, real SQLite restart/failure tests, native host checks and independent core exchange are recorded in the complete implementation evidence. Release distribution, installed interactive/spoken qualification, a real planning→shoot→edit→delivery pilot and public 1.0 adoption/governance are distinct gates. None is implied by a local test pass or by the language's existence.