Frames
A frame is a blueprint describing the whole thing rather than one unit of it. Frames set what every other blueprint is judged against, and live in the framing collection.
Every framework declares a framing collection, and declares it first.
Why it’s required
Section titled “Why it’s required”This is the only structural thing Eidos insists on beyond the five core properties:
Every framework declares a framing collection. Its name, its flavors, and how many it carries are the framework’s own — a framework needs framing, not a particular set of frames.
The reasoning is that blueprints are meaningless without something to judge them against. “Should this spec exist?” is unanswerable unless something already says who the product serves and what it’s trying to achieve. Without frames, a root becomes a pile of individually-reasonable blueprints with no shared direction — which is the failure mode Eidos exists to prevent.
What the seeds frame
Section titled “What the seeds frame”The three seeds show the same requirement answered three different ways:
| Seed | Its frames |
|---|---|
software |
architecture · audience · criteria · market |
book |
premise · reader · voice · market |
research |
question · prior work · method · ethics |
Notice these aren’t the same four ideas renamed. A research programme needs ethics framed; a book doesn’t. A book needs voice framed; software doesn’t. Your framework should frame whatever your work is actually judged against, and if that’s three things or six, that’s the right number.
What a frame looks like
Section titled “What a frame looks like”Each kind of frame gets its own flavor file, frame.<kind>.md. From the
software seed:
# {{title}}
## Shape
## Components
## Data and flow
## Boundaries and dependenciesLoose prose under stable headings. A frame records what is true now, and is revised whenever that judgment changes. Nobody should feel they need to predict the future to write one.
Frames are blueprints, not top-level docs
Section titled “Frames are blueprints, not top-level docs”This trips people up, so it’s worth being blunt about.
| Frame | Top-level doc | |
|---|---|---|
| Where | In the framing collection | At the root |
| Shape | Follows one | Has none |
| Frontmatter | Full contract | Free-form |
| Validated | Yes | No |
Listed in Framework.md under |
## Collections |
## Top-Level |
| Repeated? | Yes, one per kind | No, one of a kind |
Both are loose prose, revised in place. The difference is repetition: a shape earns its keep by being stamped again, and a document written once doesn’t need a cookie-cutter.
Fill them first
Section titled “Fill them first”The single most common way to get Eidos wrong is to skip the frames and go straight to writing blueprints, because blueprints feel like progress and frames feel like preamble.
Fill the frames first. It takes an afternoon, most of it argument, and the argument is the value — you find out that two people have been building toward different audiences before either of them writes a spec that assumes one.
Then, when you write a blueprint, you have something concrete to check it against: does this serve the audience the Audience frame describes? Does it fit the budget and timeline the Criteria frame sets? If the answer is no, you’ve found something worth knowing before the work starts.
On the canvas
Section titled “On the canvas”The software seed declares - **Canvas:** file for its framing collection —
each frame draws as a full-file node rather than a card, because a frame is prose
meant to be read whole. Blueprints in a spec collection draw as cards from one
section, because you scan those.
More on the canvas →