Blueprint updates and workspace copies

A blueprint packages a factory definition: workflows, stations, worker references, routes, contracts, policy, the factory's and stations' model policies, and memory. It does not carry your cards, credentials or run history. Connected tools and models still need configuring in the destination workspace.

A model your organization lacks is never swapped. When a blueprint's factory or station names a model your organization does not have, installing, updating or promoting it leaves that scope without a policy of its own, so its runs inherit the wider choice. The install report, the update and promotion reports and the new-factory notice list the missing models. Set a policy yourself in Models if the inherited choice is not right.

Choose a blueprint

In a workspace, open New factory and pick A factory blueprint or a file. The picker shows every blueprint you can install as a card — its name, category, where it comes from (CodeBook, this workspace or your organization) and what it sets up — under a search box and one chip per category with its count. Search reads names, summaries, workflows, station names, agents and integrations, so "Shopify", "security" or "support" finds the factories that involve them. Selecting a card shows its workflows, the agents it will install into the workspace and the tool connections it expects; none of those connections is made for you. Import from a file takes a factory exported as JSON.

Fourteen blueprints are built in:

Category	Blueprints
Software	SaaS Feature Factory, Accessibility Remediation Factory, Idea to App Factory, API Platform Factory
Security & compliance	Fintech Software Factory, Security Patch Factory, SOC 2 Remediation Factory
Commerce	Shopify Release Factory
Modernization	Legacy .NET Migration Factory
Startup	Startup MVP Factory
Agency	Agency Client Delivery Factory
Revenue	Revenue Operations Factory
Customers	Customer Support Factory
Marketing	Content Marketing Factory

The concierge can install a built-in blueprint too, after you confirm with its button.

Install and check

Choose a built-in or shared blueprint when assembling a factory. Review its compatibility requirements and scripted tests before installing. Installation into a factory with cards is refused; use an empty factory for a new installation.

Use Test factory before sending work through it. A successful simulation checks configuration, not whether a provider, repository or external tool will succeed during a real run.

Preview an update

Open Factory settings → Blueprint. The update panel identifies the source blueprint and reports whether a newer version is available.

1. Select Preview update.
2. Read the publisher changes, your changes that will be kept, and any warnings. Warnings include unknown model-policy history as well as unknown gate counting.
3. For each conflict, choose Keep yours or Use publisher’s. The preview is recalculated with your choices.
4. Check the simulation and compatibility findings. Resolve blocking requirements first.
5. Select Apply blueprint update when the preview is ready.

If the factory changes after your preview, the server refuses the stale update. Preview it again. An update that makes the simulation worse or breaks a previously passing blueprint test requires an explicit acknowledgement; unresolved conflicts cannot be overridden.

Applying an update creates a factory version. Use Versions to compare definitions or roll back. An archived or inaccessible source stops offering updates without deleting the installed factory.

Make your own copy

In the same panel, enter a name under Make your own copy, then select Create private blueprint copy. The published blueprint is copied into your workspace with its tests and dependencies. It can develop independently of the publisher’s version.

This copies the published blueprint, not the current factory’s unpublished customizations. Use the existing blueprint publishing flow when you want to publish your factory’s current definition instead.

Readers can inspect updates. Applying an update requires write access to the factory; creating a copy requires write access to the workspace.

Where the factory is a stage of an environment chain that requires another person's approval, installing a blueprint into it or applying an update opens a change request instead of writing directly; a second person publishes it.

Idea to App Factory

The one built-in blueprint that starts from nothing. Put a sentence on a card in the Idea station — make me a to-do list app — and the factory works it through three workflows without anyone moving a card:

1. Idea & epics. The Idea station starts on arrival. Agents work out who the application is for, its shape (data, modules, the command that runs it and the one that tests it) and the alternatives, each as a typed artifact. The Epics agent then writes three to six epic cards straight into the Backlog of the build workflow.
2. App build. Backlog starts on each new epic and breaks it into three to six stories with acceptance criteria, filed at Design, which starts on each one. Development — the only station allowed to write to the repository — builds the story and opens a draft pull request. QA reads the diff against every acceptance criterion and fails the story back with findings. Human review is a person, and nothing reaches Done without one.
3. Bugs. A defect QA finds in something already built is sent here — Reproduce, Fix, Regression — instead of blocking the build.

Before the first run, give the build workflow a repository and set a model that can write code in the factory's model policy. Until then every station reports blocked and the card says why.

What it does not do:

• It does not run the application. No station can build the project or run its tests. QA judges the diff and counts anything that needs a run to settle as not met.
• It does not serialise Development. Several stories are built at once from the same starting point. A pull request that carries only its own story's change can conflict with its sibling, and nothing orders the merges yet.
• Its output is only as good as the model. The pipeline has been run end to end with a scripted stand-in model that writes a fixed application; that proves the machinery, not the judgement of a real model.