Skip to content

Frames

A frame is a blueprint describing the whole product rather than one unit of it: who it serves, what it is trying to achieve, how it is built. Every other blueprint is judged against them. Frames live in a framing collection, a collection like any other, whose templates are named frame.<variant>.md.

The standard does not require one. Every seed opens with one, eidos install includes it unless you pass --no-framing, and Eidos recommends one for every product.

“Should this spec exist?” is unanswerable unless something already says who the product serves and what it is for. Without frames, a root becomes a pile of individually reasonable blueprints with no shared direction.

Seed Its frames
software architecture · audience · criteria · market
book premise · reader · voice · market
research question · prior work · method · ethics

These are not the same four ideas renamed. Research needs ethics framed; a book needs voice. Frame whatever your work is actually judged against, whether that is three things or six.

Each kind of frame is its own variant. From the software seed:

.eidos/templates/frame.architecture.md
# {{title}}
## Shape
## Components
## Data and flow
## Boundaries and dependencies

Loose prose under stable headings, recording what is true now and revised whenever that judgment changes. Frames sit flat in their collection, one file per kind.

Both are loose prose revised in place. The difference is repetition: a frame follows a template, carries the property contract, and is validated, because there is one per kind. A top-level doc is written once and gets none of that.

The most common way to get Eidos wrong is to skip the frames, because blueprints feel like progress and frames feel like preamble. Filling them takes an afternoon, most of it argument, and the argument is the value: you find out that two people were building toward different audiences before either wrote a spec that assumed one.

A declared frame left unwritten is a gap eidos check surfaces, never a failure.