Why Eidos Exists

The problem

Ask a team what they are building and you get four answers, none written down in one place. The ticket closed eighteen months ago. The wiki page was accurate the week it was written. The decision not to support a case was made out loud, and the person who remembers it left. The code says what the thing does today, not what it is meant to be.

So the honest answer to “what is this supposed to be?” is a meeting.

Why tickets can’t hold it

A task describes work. It has an owner, an estimate, and a state that runs from open to closed. Its purpose is to stop mattering. When the work ships, everything the ticket recorded about the product goes stale in the same instant.

A blueprint describes a piece of your product. It is written before the work starts, corrected while the work happens, and stays accurate after. It has no end.

This is why Eidos forbids work-tracking fields: no sprint, estimate, or assignee. Add them and a blueprint becomes a task and rots on the same schedule. Link to your tracker instead.

What Eidos does about it

It keeps the answer to “what is this thing” as markdown, in the repository, next to your product, reviewed in the same pull requests.

Next to your product, so it is in front of the people who would otherwise guess.
In git, so every change has an author, a date, and a diff. Eidos leans on that history instead of inventing its own audit trail.
Plain markdown, so a person and a coding agent read the same file. Two sources of truth is how drift starts.

Why a person has to author it

A spec is a check on the code. A check only works if it comes from somewhere else.

Let an agent write the spec, then the code, then check the code against its own spec. Everything agrees. Nothing has been verified: two outputs of one process corroborating each other tells you nothing about either.

A blueprint is worth exactly as much human intent as went into it. One with none is worse than no blueprint, because it carries the authority of being written down.

When not to use Eidos

If you are going fully autonomous, with no review and the agent choosing direction, don’t write blueprints. They add ceremony, not correction. Let the code be the source of truth, because it already is. For a prototype or a throwaway, that is the right call.

Eidos is for the case where someone is accountable for what the thing is: a person who has to defend a scope decision, or explain in a year why it doesn’t handle a case someone assumed it did.

What it is not

Not a project management tool. It answers “what is this”, never “how is it going”.
Not a documentation generator. Nothing is derived from code. A person decided something and wrote it down.
Not a form to fill in. If a blueprint reads like boilerplate, reshape it until it reads like someone wrote it.
Not a rigid structure. The standard names no collection, template, or section. Your framework names everything.

Who holds it

The people who own the product: they hold the intent, the scope, and the decisions, whatever role each has. A root with no owner becomes a wiki with better formatting: everyone edits, nobody decides, and the non-goals quietly empty out, because saying no takes authority.