Framework & Blueprint

Eidos turns on two words. Get these straight and the rest of the standard falls into place.

	Framework	Blueprint
What it is	The form	One unit, defined completely
Is	Collections, shapes, flavors, roles, naming convention, Schema	One markdown file: frontmatter plus a body
Lives in	_eidos/, hidden at the root	A collection folder
Portable?	Yes — this is the piece one team hands to another	No — it’s your product
Relationship	One framework	Governs any number of blueprints, in any number of roots

The name

Eidos (εἶδος) comes from ἰδεῖν, to see — literally the look of a thing, its visible shape. Plato took it for the Form: the pattern a thing conforms to, which the eye never catches and the mind does. Aristotle set it against ὕλη, matter — form is what makes a lump of stuff that particular thing.

Both senses are load-bearing here. The framework is the form; a blueprint is what takes that form.

A third word, doing less work

root — the one folder Eidos lives in, holding the framework, the collections, and any top-level docs. It’s found by the hidden _eidos/ inside it, never by its name.

It isn’t part of the pair above because it names a location rather than an idea. Through 4.4.0 the whole tree was called a definition; that collided with what a blueprint does, so 4.4.1 dropped it and 4.4.2 settled on root.

The root

One folder, which may be named anything — Blueprints/ is only the default install offers — because nothing points at it by path. It is found by the hidden _eidos/ inside it.

• DirectoryBlueprints/ the root

  • README.md the visible “start here”
  • Directory_eidos/ the framework

    • …
  • Directoryframes/ the framing collection — declared first

    • index.md generated leaf
    • architecture.md one per kind of frame, flat
  • Directoryspecs/ a collection of blueprints

    • index.md generated leaf
    • Directoryplayback/ one level of sub-folders, at most

      • resume-playback.md one blueprint per file
  • roadmap.md a top-level doc — optional, yours

Several roots can live in one repository. They nest as Blueprints/<name>/…, each with its own _eidos/.

The framework

The framework is hidden the way .git and .obsidian are hidden: present, manageable, and out of the way once it’s set. That placement is deliberate — the root is plausibly an Obsidian vault, and _eidos/ sits beside .obsidian/ without competing with the content for attention.

• Directory_eidos/

  • Directoryshapes/ one file per flavor

    • spec.full.md a collection’s default flavor
    • spec.micro.md a second flavor of the same kind
    • frame.architecture.md the framing collection’s flavors
  • Directoryroles/ response contracts, committed and team-tunable

    • framework-owner.md the one every seed carries
    • developer.md the rest are the framework’s own
  • Framework.md index + config: version, naming, collections, Schema
  • me.md the actor (personal, gitignored)
  • .gitignore ignores me.md — the one file here not committed

A folder with no _eidos/ is not a root.

Framework.md

The one file describing the form rather than any single blueprint. Frontmatter for the facts tooling parses; a body indexing the root.

_eidos/Framework.md — frontmatter

---
eidos_version: 4.4.2      # the standard version this framework targets
naming: kebab-case        # kebab-case | TitleCase | Title Case; absent = kebab-case
---

The body carries four things:

## Top-Level — the one-of-a-kind documents at the root, README first. Framing docs are not here; they are a collection.

## Collections — one ### heading each, declaring its generated leaf, its flavors (with one marked default), how the canvas should draw it, and its grouping.

_eidos/Framework.md — a collection

### specs

The product's units, one per blueprint, grouped by domain.

- **Leaf:** [specs/index.md](../specs/index.md)
- **Flavors:**
  - [full](shapes/spec.full.md) — the complete spec shape (default).
  - [micro](shapes/spec.micro.md) — Intent, Open Questions, ACs, Out of Scope.
- **Canvas:** card from `## Intent`
- **Domains:** _(one bullet per domain as they accrue)_

## Schema — the property contract, split into ### Eidos Core (the standard’s, rewritten by migrate — don’t hand-edit it) and ### Custom Properties (yours). More →

Canvas hints

- **Canvas:** tells canvas how to draw a collection: file for a full-file node (prose read whole), card for a node embedding the blueprint, or card from ## Section to embed one section. Absent means a plain card — the generator knows no collection by name and cannot guess which section is the summary.

Why the split matters

Because the framework is the piece that travels.

Your blueprints are your product, and they’re useless to anyone else. A framework is form with no content — collections, shapes, a schema, roles — and it’s exactly the artifact one team hands to another so both write the same way. That is the whole reason the seeds exist: they are frameworks Eidos ships, and install copies one into a new root.

It also explains the convention that surprises people most:

The folder owns its framework

Shapes and properties live in the root’s _eidos/. A skill reads the framework from the root, never from a copy of its own. There is no global config, and no tool has a hardcoded idea of what your collections are called.

Validation follows from that. A check reads that framework’s Schema and enforces it — the core properties plus the custom ones scoped to the blueprint’s collection. The contract is the Schema, not a rule baked into a tool.

Next

• Collections & Blueprints
• Shaping Your Framework