Design Document Format & Versioning

Every design you create in Lega is saved as a structured document — not a flattened image, and not an opaque binary blob. Understanding roughly what's in that document, and how Lega keeps old documents working as the editor evolves, is useful even if you never touch it directly.

What's actually in a design document

A Lega document is a description of your design as data: a list of frames (your artboards), and within each frame, a tree of layers — text, shapes, images, decorative elements, and groups of any of those — each with its position, size, style, and content. Nothing about a design's appearance is baked into pixels until export time; the document is the source of truth, and both the live canvas and the exported output are rendered from it. This is the same principle covered in more depth in the editor architecture overview: one compiled representation, multiple ways to draw it.

Because the document is structured data rather than a picture, it stays fully editable indefinitely — reopening a design a year later gives you back real layers you can select and change, not a picture you'd have to trace over.

Why documents carry a version number

Software evolves. Over time, Lega adds new layer capabilities, changes how certain properties are represented internally, or refines how a feature is structured in the saved document. If documents had no way to signal which "shape" of the format they were saved in, the editor would eventually face an impossible choice: either freeze the format forever (blocking new features) or risk misinterpreting older documents saved before a change.

Lega avoids that by giving every saved document a schema version — a marker that says, in effect, "this document was saved when the format looked like this." The version travels with the document itself, so the editor never has to guess.

Migrate-on-read

The mechanism that makes versioning actually useful is what's typically called migrate-on-read: when Lega opens a document, it checks the document's schema version against the current one. If they match, nothing special happens. If the document is older, Lega runs it through a sequence of small, targeted transformations — each one upgrading the document exactly one version forward — until it's expressed in the current format. The upgraded result is what the editor actually works with.

A few properties fall out of this approach that are worth calling out:

• Old designs keep opening correctly. You're never asked to "convert" a design manually, and a design saved months or years ago opens the same way a design saved five minutes ago does — behind the scenes, it's simply brought forward through the same chain of upgrades every older document goes through.
• Migrations are incremental, not monolithic. Because each migration step only needs to handle the jump from one version to the next, the upgrade logic for going from version 3 to version 7, say, is really four small, independently reasoned-about steps chained together — not one large, error-prone leap.
• Validation happens at the boundary. Both reading and writing a document pass through validation, so a malformed or partially-upgraded document can't silently reach the canvas, the AI generation pipeline, or an export. If something doesn't conform to the expected shape, it's caught at the boundary rather than causing subtle rendering bugs downstream.
• New features don't retroactively break old files. Adding a new layer capability or property doesn't require rewriting how existing documents are interpreted — older documents simply migrate forward and pick up sensible defaults for anything new.

Why this matters for AI-generated content specifically

AI-generated layouts go through the exact same read/write and validation path as anything created by hand — there is no separate, less-scrutinized channel for AI output. A layout the AI produces is written to the document format, validated the same way an manually-edited document would be, and, on the next read, subject to the same migrate-on-read handling as any other saved design. That consistency is part of what lets AI generation and manual editing be freely mixed within a single session, as described in the editor architecture overview — the document format doesn't distinguish where a layer came from, only what shape it's in.

What this means for you, practically

You don't need to think about schema versions day-to-day — that's the point of migrate-on-read. The practical upshot is durability: a design you build today will still open correctly, with every layer intact and editable, long after the editor underneath it has changed. When you're ready to take a design out of Lega entirely, see Exporting Your Design for how the same underlying document gets turned into a final output file.