Conventions

EIDOS.md closes with nineteen load-bearing conventions. They’re a flat, numbered list there; here they’re grouped by what they govern, with pointers into the pages that explain them.

Don't cite them by number

The numbering is not stable — 4.4.2 took the list from twenty-four to nineteen and renumbered what remained. Cite what a convention says, not where it sits. This page names them for that reason.

What is enforced, and how

The frontmatter is the agreement; the body is guidance. Properties are checked against the framework’s Schema. Body sections are recommended structure, not requirements.

Validation is framework-defined. A check reads that framework’s Schema and enforces it. The contract is the Schema, not a rule hardcoded in a tool.

Portability over prescription. A missing core property is surfaced and added with a note on why; a missing section is noted and offered. Never refuse the file.

The posture these three set

Eidos surfaces rather than blocks. Validation output is a review a human acts on. A validator that refuses files gets bypassed, and a bypassed validator flags nothing. More →

Where the form lives

The root owns its framework. Shapes and properties live in the root’s _eidos/. A skill reads the framework from the root, not from a copy of its own. →

Every framework declares a framing collection. Its name, its flavors, and how many it carries are the framework’s own. Required as a declaration; never a gate — a declared frame left unwritten is a gap to surface, not a failure. →

Shapes and collections

One shape family per collection, declared as flavors. What flexes is which sections appear and which flavor a blueprint uses — never their order or names within a flavor. The shape is never forked per category.

A shape names its own stable part. Every shape has a part that holds still and a part that moves, and says which is which. If the stable part changes substantially, ask whether this is a different blueprint. →

Non-goals carry the most weight. Where a shape declares a section for what a blueprint deliberately will not do, that section is its strongest — it is where scope management actually happens. Still not a hard gate. →

A shape documents its own conventions. Section names, their order and meaning, and any labeling a shape asks for live in the shape file. The standard governs collections, shapes, flavors, and properties; it never governs a section.

A collection’s grouping is the collection’s own. It may group its blueprints one level deep and may declare a property naming that grouping; the value then matches the folder, and an unknown value warns rather than blocks.

Properties

Properties carry a type and a meaning. Every property declares its name, its type, which collections it applies to, and what it means. Frontmatter is generated from the Schema, so a new blueprint is born conforming.

Soft labels are views, not structure. A category label a framework adds drives views and filtering, never structure. An off-list value is valid. flavor carries the structural choice.

The Eidos version is a framework fact. It lives in Framework.md, never as a per-blueprint property. Git holds the history; a framework that wants date properties declares them like any other. →

No work-tracking fields

No sprint, estimate, or assignee — the moment you add them, a blueprint becomes a task and rots. Bridge to a tracker with a link. The same holds in the body: a section describing how you mean to build a thing captures intent, never how far along it is. Why →

Writing

Write it like a human would read it. The sections are a scaffold for a living blueprint, not a form to pour text into. If a blueprint reads like filled-in boilerplate, reshape it until it reads like someone wrote it.

Reference other blueprints with links, not bare names — in prose and in properties alike. Each blueprint’s id is still its permanent identity, sitting behind the link.

Loose prose is revised in place. A top-level doc, and any collection a framework marks as loose prose, records what is true now and is expected to change. That is revision, not work status.

Who does what

The human authors; the agent facilitates

Intent, scope, and decisions stay with the person. An agent formats, supplements, asks, and holds scope; it does not generate finished blueprints or set direction. A blueprint the owner did not think through is worse than none. →

Read the actor before acting. Read _eidos/me.md and the matching contract in _eidos/roles/, and respond as that role defines. The human-first principle holds for every role; only the mode changes. A blank or absent file defaults to full facilitation. →

What used to be here

Five conventions were dropped in 4.4.2 — restated elsewhere, not relaxed. Each still holds; it just isn’t carried as a numbered rule:

Dropped	Now lives in
id is permanent	The Schema table
Human-facing names follow the naming convention	Naming
Framework.md is the index; README.md is the door	Framework & Blueprint
Each collection has a generated index	Generated Leaves
Top-level docs have no shape	Shapes & Flavors

The old rule mandating date_created and date_modified also went. It told frameworks how two properties must behave, while the Schema section says Eidos defines no custom properties at all. A framework already using them changes nothing — it now simply owns them outright.

If you only remember three

The human authors. Everything else is downstream of it.

Non-goals carry the most weight. It’s where scope is actually held, and the first section to go empty when nobody owns the root.

No work-tracking fields. It’s the line between a blueprint that stays true and a ticket that rots.

Next

• Glossary
• Versioning