Blueprints

Install a blueprint and it builds the feature for you: the collections, the roles, the permissions, the flows, the pages — all created in one go, exactly as you approved them. Nothing is written until you have seen the plan and said yes.

#One document, one feature

A blueprint is a single Markdown file, .ebp.md. Between its paragraphs sit fenced blocks called bricks, and each brick is one thing the install creates: a collection, a role, a set of permissions, a flow, a page, a row of seeded data. The prose around them is not decoration — it is what you read beside each tick when you approve the install.

It carries no code and runs nothing of its own. Every brick becomes an ordinary call to this platform's own API, made as you, under your own permissions, so a blueprint can never reach further than the person installing it.

#Nothing happens until you say so

Installing runs in four steps, and the first two write nothing at all:

1. Validate — is this a document this platform can read?
2. Plan — what would it do to this project? A verdict per brick: what would be created, what already matches, what has been edited by hand since.
3. Consent — you tick what you accept. The plan is the thing you are approving.
4. Execute — the calls run, and a ledger records what each one actually produced.

Install one walks all four.

#Where to go next

Page	What it answers
What it can do	Is this worth using? Six situations, in plain language
Install one	The walk: validate, plan, consent, execute
Update and uninstall	What changes on a second install, and what removing one leaves behind
Examples	The documents that ship in the repository, and one read end to end
Write your own	Authoring: the decisions that are yours, and the loop for getting them right
Reference	The wire format, the brick kinds, the diagnostics and the install ledger

If you are looking for the REST endpoints, they are on Reference — the API reference points there too.