Skip to content

Properties

The Properties table is the framework’s whole property contract, under properties in Framework.yaml. Frontmatter is generated from it, so a new blueprint is born conforming.

Every property declares:

Field Meaning
name The frontmatter key
type Text, List, Number, Checkbox, Date, or Date & time: the set Obsidian renders natively
applies_to all, or a list of collections
required Absent means false
options Only when the value is one of a closed set: the allowed values, in order
meaning What it is for, in a sentence

Anything that wants more structure than one of the six types belongs in the body.

applies_to is what stops a property landing where it makes no sense. domain applies to specs only in the software seed, so a frame never gets one.

required puts the property on every new blueprint and makes a missing or blank one a gap the check notes. An optional property is written when it has a value; its absence is never a gap. Default to optional, and require only what every blueprint must answer.

options closes a Text value (or a List’s elements) to a declared set, compared exactly. A value off the list is surfaced with the list beside it, never refused and never swapped in silently. The order is the order the values run, so a lifecycle reads first stage to last and a dropdown keeps it. No default rides with it. Two properties never carry options: variant, whose set is the collection’s variants, and a grouping property, whose set is its groups.

The whole of what the standard declares:

Name Type Required Meaning
id Text yes Stable, unique identity, in any form. Assigned once, never changed
title Text yes Human-readable name. Rename freely; id holds still
summary Text no One line: what this blueprint is. Feeds the index; absent, the index flags it
variant Text no Which variant this blueprint follows. Absent means the collection’s default

Status, dates, grouping, dependencies: all the framework’s choice. The software seed ships these, and every one is yours to keep, scope, or drop:

Name Type Applies to Meaning
status Text all Lifecycle stage. Options: Draft, Intake, In Progress, Done, Archived, Deprecated
date_created, date_modified Date all YYYY-MM-DD
tags List all Free tags
domain Text specs The group, matching the sub-folder. The one property the seed requires
depends_on List specs Blueprints this one needs, each a markdown link
type Text specs Soft label: feature, capability, integration. Drives views, never structure

Add one with eidos configure:property add. Shaping your framework →

Soft labels are views, not structure. A category property drives filtering, never which sections a blueprint has. If it starts to, it is a variant.

A grouping value matches its folder. Exactly, in the naming convention. An unknown value warns.

No work-tracking fields. No sprint, estimate, or assignee. Link to your tracker. Why →

Dates and history are not the standard’s business either: git holds the full history, which is why Eidos never reinvents an audit trail in frontmatter. The Eidos version is a framework fact, in eidos_version, never on a blueprint.

Beside the properties, the framework declares its vocabulary: one entry per word the product is described in on purpose, with what it means, what it is not (the near-misses and why), and see for the blueprint that defines it in full. Eidos declares none; every seed ships the list empty. Where a term is declared, blueprints use it; a near-miss is flagged (term-near-miss), never swapped silently.

Validation is framework-defined. A check reads that framework’s table and enforces it. Surface, never refuse. A missing required property is reported; a missing section is offered; the file is never rejected. The output is a review a person acts on.

In the CLI: eidos new generates the frontmatter; eidos property set changes one value, typed; eidos check validates against every block. In the browser, a property with options is a dropdown.