The record every layer below reads from, and no prompt can edit.

Changes arrive as named operations

An agent cannot rewrite a Blueprint in prose. It proposes operations against named elements — add a step to a workflow, move a transition, name the role that signs the step off — and anything that is not a legal operation on an existing element is rejected before a reviewer sees it. A named operation on a named element is something validation can evaluate; a paragraph of instructions is not.

The stack stays out of it

Meaning lives in the Blueprint. Frameworks, databases, hosting and API style live in the generator and the target adapter, and the split is held by the schema rather than by convention: a Blueprint has no field a framework name would fit into. Swapping the target re-runs generation against the same record, which is why one Blueprint can produce a web application, a mobile application, an API or an internal tool.

Every publish leaves a version

Publishing creates a version that stays readable, alongside the operations that produced it and the approvals it passed. A release points at a specific Blueprint version, so the question "what was this product supposed to do when we shipped it" has an answer rather than an archaeology project.

It knows what already exists

A Blueprint records which capabilities the product consumes and at which version, not just what it needs in the abstract. When a shared capability changes, the products that will feel it are already listed, because the dependency was written down at specification time rather than discovered in production.