Where the editor ends and the model begins.

In most tools there is a seam. You export, you upload, you wait, you download, you put the result back and hope it still lines up. On one side of that seam is your project; on the other is a program that has never heard of it. Sparkle does not have the seam, and removing it is most of the engineering on this page.

An editor is a document and the operations that change it

Underneath the panels, an editor is one thing: a document describing what happens when, and a set of named operations that are the only way to change it. Split a clip, retime it, set a colour, add a caption track. Nothing else touches the document.

That sounds like an implementation detail and it is the whole architecture. Once the operations are the only door, everything that matters later — undo, concurrency, replay, an audit of what happened — is a property of the door rather than something bolted onto each feature that walks through it.

So the assistant is another caller, not another program

The assistant does not generate code, and it does not generate frames. It emits the same named operations a menu item emits, with the same typed parameters, into the same document. Ask it to cut a vertical version and it calls the operation the editor already had.

Two things follow, and both are the point. It cannot express anything the editor cannot do, so there is no category of AI output that has to be reconciled with the project afterwards. And anything it did, you could have done — which means you can read it, change it, or take it apart by hand.

One operation, one undo

An assistant operation can touch a hundred clips: retime them, recolour them, restyle every caption. It still collapses to a single checkpoint, so one undo puts you back to before you asked.

This is not a convenience. What makes an editing assistant usable is not how often it is right — it is how cheap it is to disagree with. An assistant you cannot cleanly reject is one you have to supervise, and supervising it costs more than doing the work.

The model is the easy part. Everything around it is the editor.

Two hands, one document

While a long operation runs you keep working, so the document has two authors. The naive version of this loses an edit: the slower writer saves last and quietly overwrites what the other one did.

Every save is a compare-and-swap against the document's current head operation. A write built on a version that has moved is refused, not merged and not silently applied. Refusing is the useful behaviour — a rejected save can be retried against the truth, while a lost edit is discovered days later by the person who made it.

Exactly once, or not at all

A step of an assistant plan will eventually meet a retry, a double click, a lost connection, a refresh, a crash halfway, or two executors that both believe they own it. Any of those can apply an edit twice, and an edit applied twice to a timeline is not a duplicate — it is a different timeline.

So the executor is not allowed to decide. Before it changes anything it has to claim the step from the plan store, which grants it atomically under a lock; only a granted claim authorises the edit, and a replay returns the first result without touching the document. What proves an operation happened is a recorded operation id, not a flag in a browser tab.

The models sit beside the timeline, not behind an upload

Matting, segmentation and depth run in the same process as the editor, on the frames it already has in hand. There is no export, no upload, no waiting, no re-import, and nothing to line back up afterwards.

That is a design choice about latency, and it settles a question the seam usually leaves open: footage under embargo stays under embargo, because it never left. Where work genuinely needs the cloud it goes through one gateway that meters it against the account that asked for it.

A preview that is the export

The same shaders draw the scrub and the final render, so what you approve is what you ship. Without that, every AI edit is provisional: you would be accepting a picture and re-checking the file later, which is the seam reappearing at the other end of the pipeline.

Taken together — one document, one set of operations, one undo, one head, one execution, one render path — the interesting question stops being how good the model is. It becomes how cheaply you can disagree with it. That is the part we build.