Reference Boards: Point, Don't Copy

"A board remembers where every reference sits and how big — but it never holds the reference. Owning the layout is not owning the library."

A PureRef, but Durable and Owned

Reference boards are the familiar reference-board surface — an effectively unbounded canvas where you pan, zoom, and arrange reference images to study them, in the spirit of a tool like PureRef. The difference is that Loomis owns the boards, because a board is genuine art-study state: the way you laid out your references is part of your practice, and it must survive a browser refresh, a change of origin, and a move to another device. So a board isn't trapped inside a desktop app's local file — it's durable, portable state the engine keeps.

Reference, Never Copy

Here's the ownership move. A board arranges Eagle references by id — it stores a pointer to each original, (source_id, item_id), and reads through to the real image. It does not copy Eagle's library into a second Loomis library. What the board actually stores is the arrangement: where each reference sits, how big, rotated how, its z-order, whether it's locked, a non-destructive crop. Position and pixels are kept strictly apart — Eagle owns the pixels, the board owns the positions. Change the original in Eagle and every board pointing at it just reflects the change, because there was never a stale copy to fall out of sync.

The Scoped Fallback

There's exactly one exception, and it's deliberately narrow. An image pasted or dropped directly onto a board — not picked from Eagle — does get board-local bytes, because there's no Eagle id to point at. But those bytes are scoped hard: addressable only through the owning board, never silently entering Eagle, and deleted with the board. It's a fallback for convenience that refuses to grow into a second general library. The narrowness of the exception is what keeps the ownership rule intact — one small, bounded place for orphan bytes, and nowhere else.

Ownership Boundaries Keep Systems Small

Step back and it's the family's single-responsibility discipline applied to media. Eagle owns the originals. Loomis owns the arrangement. Cinder owns the native, always-on-top shell. Each system owns exactly one thing and references across the boundary rather than absorbing its neighbor's job. This is why no piece becomes a bloated everything-store: the board never becomes a media library, Loomis never becomes Eagle, and the desktop shell stays Cinder's. The same rule runs through the whole family — binaries stay with their owning system, and everyone else holds a reference, not a copy.

Code

A board stores arrangement, not pixels·python

# A board stores ARRANGEMENT, not pixels. Eagle owns the originals.
class BoardItem:
    ref: EagleRef          # (source_id, item_id) -- a POINTER, read-through
    transform: Transform   # position, scale, rotation, z-order, lock, crop
    # NOTE: no image bytes here. The board never copies the original.

# The ONE exception -- images dropped DIRECTLY onto the board -- is scoped hard:
class BoardLocalImage:
    data: bytes            # owned by THIS board only, never enters Eagle
    transform: Transform   # deleted with the board; not a second library

# Eagle owns originals. Loomis owns arrangement. Cinder owns the native shell.
# Reference across the boundary; never absorb the neighbor's job.

Exercise

Find a case where you (or a system you use) copied data across a boundary — duplicated a source file into a second app, exported a dataset into a second store, pasted the same content into multiple documents. What sync or drift problems did the copies cause over time? Sketch how referencing the original by id (read-through) instead of copying would have removed that whole class of problem.

Hint

Copies across a boundary create the reconciliation tax: every change to the original must be manually propagated, and any missed propagation is silent drift. Referencing by id removes it entirely — there's one authoritative copy, and every consumer reads through to it, so there's nothing to keep in sync. The cost is a live dependency on the owner; the benefit is that drift becomes impossible.