Schema

The Schema is the framework’s whole property contract: the core properties Eidos requires, plus whatever the framework adds. It lives in one place — ## Schema in _eidos/Framework.md — and frontmatter is generated from it, so a new blueprint is born conforming.

Every property declares four things:

Field	Meaning
Name	The frontmatter key.
Type	One of Text, List, Number, Checkbox, Date, Date & time.
Applies To	all, or a list of collections.
Meaning	What it’s for, in a sentence.

Why those six types

They’re the set Obsidian uses, so frontmatter renders natively in a vault. Anything that wants more structure than one of them belongs in the body, not in a property.

Applies To scoping

This is the part that does real work. Frontmatter is generated per blueprint from the properties that apply to its collection, so a scoped property never lands where it makes no sense.

domain is a specs-only property in the software seed. A frame never gets one, because a frame isn’t grouped by domain — and that’s enforced by generation, not by asking people to remember.

The core

Present on every blueprint, and the whole of what the standard requires:

Name	Type	Meaning
id	Text	Stable, unique, kebab-case identity. Assigned once, never renamed. References point at it.
title	Text	Human-readable name.
summary	Text	One plain line: what this blueprint is. The source for the collection’s index.md listing; absent, the index flags it.
flavor	Text	Which flavor this blueprint follows. Absent = the collection’s default.
connects_to	List	Blueprints this one connects to on the canvas, each a link, drawn as a directed edge.

Five properties. That’s the entire required contract.

`id` is permanent

Stable, unique, kebab-case, assigned once, never renamed. Rename title freely — it’s the human label. The id is the identity that links, references, and history hang off.

Don't hand-edit the core block

### Eidos Core in Framework.md is the standard’s block. migrate rewrites it on a version change. Your properties go under ### Custom Properties.

Eidos defines no custom properties

A lifecycle status, dates, a grouping, a dependency list — all of these are a framework’s own choice, not the standard’s. Each seed makes its own set.

The software seed ships these, and every one of them is yours to keep, scope, or drop:

Name	Type	Applies To	Meaning
status	Text	all	Draft / Intake / In Progress / Done / Archived / Deprecated. An off-list value warns.
date_created	Date	all	YYYY-MM-DD. The day the blueprint was first written. Set once.
date_modified	Date	all	YYYY-MM-DD. The day it was last changed.
tags	List	all	Free tags.
domain	Text	specs	The grouping, matching the blueprint’s sub-folder. An unknown value warns.
depends_on	List	specs	Blueprints this one needs, each a markdown link. An implementation dependency, not a canvas edge.
type	Text	specs	Open, soft category label — feature, capability, integration. Drives views, never structure.

Add one with configure, which presses for all four of Name, Type, Applies To, and Meaning, then backfills the blueprints it applies to.

Three property conventions worth internalising

Soft labels are views, not structure

type is the example: a category label drives views and filtering, never structure. An off-list value is valid.

If a label starts changing which sections a blueprint has, it isn’t a label any more — it’s a flavor, and flavor is the property that carries structural choice.

A grouping’s value matches its folder

If a collection declares a property naming its grouping, the value matches the sub-folder exactly, in the framework’s naming convention. An unknown value warns rather than blocks — groupings accrue over time, and the validator is the wrong place to litigate them.

No work-tracking fields

The one worth refusing on. No sprint, estimate, or assignee. Bridge to your tracker with a link. Why →

connects_to versus depends_on

Two link-list properties that look alike and mean different things. Worth getting right, because only one of them draws.

connects_to is core. It is the intentional map: what you are asserting relates to what, for a human reading the root spatially. canvas draws each entry as a directed edge.

depends_on is the software seed’s own property. It’s an implementation dependency — what this needs in order to be built. Not a canvas edge, though canvas can overlay it in a distinct colour if you ask.

The distinction is intent versus mechanism. Two blueprints can depend on each other technically while having nothing to say to each other conceptually, and the reverse happens just as often.

Dates and history

The Eidos version is a framework fact, in Framework.md. It is never a per-blueprint property.

Dates are not the standard’s business either. Through 4.4.1 it mandated how date_created and date_modified behave; 4.4.2 dropped that, because it sat badly beside a Schema section stating that Eidos defines no custom properties at all. A framework that wants date properties declares them like any other, and owns what they mean.

Why the standard can afford to stay out of it

Git holds the full history — that’s the point of living in a repository, and the reason Eidos never reinvents an audit trail in frontmatter. The software seed still ships both date properties; they’re just its choice now, not a rule.

Validation

Validation is framework-defined. 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 hardcoded in a tool.

And the posture is 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 output of validation is a review a human acts on, not a gate that stops them.

Next

• Frames
• Shaping Your Framework — adding a property and backfilling it.