Blueprints

Blueprints are human-readable technical specification documents that serve as the definitive source of truth for how a system should be built. They translate product requirements into precise engineering guidance that you keep in sync with the code.

Blueprint types

Every project starts with three blueprint categories in the navigator: Containers, Components, and Feature Blueprints.

Container Blueprint

A Container Blueprint describes a single deployable or runnable unit of the system, such as a web application, API server, database, background worker, or build pipeline. It captures the container's technology stack, runtime characteristics, and cross-cutting concerns such as authentication, error handling, and observability.

Container Blueprints are infrastructure-focused and feature-agnostic. They establish the operational context that Component Blueprints build within.

Component Blueprint

A Component Blueprint describes a reusable system capability composed of multiple components such as services, controllers, hooks, and strategies that together power one capability, for example identity and session management or notification delivery.

Component Blueprints are feature-agnostic and commonly span multiple containers. They describe what the system can do, not what any single feature uses.

Feature Blueprint

A Feature Blueprint describes how capabilities from Component Blueprints combine, plus any feature-specific components, to satisfy product Requirements. Each Feature Blueprint corresponds to a Feature Requirements Document: Requirements say what, while the Feature Blueprint says how.

Feature Blueprints are composition-first. They connect shared capabilities, configure them for the feature, and document feature-specific glue. Together, the blueprint types form a technical narrative spanning infrastructure, reusable capabilities, and feature implementation.

The Feature Blueprints section mirrors the Feature Requirements tree. You add, rename, and remove features in Requirements, and write each feature's blueprint here.

Custom categories

Add your own category with New Category at the bottom of the navigator. To rename or delete a category, open its menu in the navigator. A category must be empty before you can delete it.

Under Settings → Modules → Blueprints, Category Management lets you rename each category and set its Initial Content, the starting text for new blueprints in that category. Below it, the Feature Blueprints card sets the starting text for new feature blueprints. That category can't be renamed or deleted.

When the agent writes blueprints, it follows the project's Blueprints Writing Rules skill.

Navigate blueprints

The navigator lists every blueprint. Use its view picker to switch between three views:

• Tree shows the categories and their blueprints in their saved order.
• A–Z lists every blueprint by title.
• Recently edited puts the blueprints with the latest changes first.

The view picker also has a Filter by title box.

Edit, suggest, and review

Use the mode selector at the end of the formatting toolbar to choose how you work:

Editing and Suggesting need Editor access to Blueprints. Viewers read blueprints in Viewing mode and don't see the selector.

Suggestions appear inline in their author's color. Each suggestion also has a thread that shows where it came from: a person, the agent, an automation, an MCP client, or the external API. Select Accept or Reject on the thread to resolve it.

The changes navigator steps through changes one at a time. By default it shows the changes your agent made for you, and you can filter it by author and by source (All, Manual, or Agent). Accept All and Reject All resolve every change the navigator is showing in the current blueprint. When changes span several documents, the navigator also takes you to the next document to review.

Comments

Select text and choose Comment to start a thread on that passage, or Ask agent to bring the passage into the agent chat. You can also open the Comments panel and select Add Comment.

• Filter the panel to Open or Resolved threads. Resolve a thread with its check button, and reopen it with Re-open thread.
• Threads you have not read show a dot, and the navigator marks blueprints that have unread comments. Use Mark read or Mark unread from a thread's menu.
• Copy Link copies a link to the thread. Opening the link takes you to the blueprint and shows the thread beside its passage.
• Reply to a thread from the reply box at its bottom.
• Drag the edge of the Comments panel to make it wider or narrower. It keeps its width when you close and reopen it.

Version history

Select Version History in the panel controls to see how blueprints changed. Versions are saved automatically as people and agents edit, and each version covers every blueprint in the project.

• History lists versions. Filter them by This Document, All, or Named. Select New to save a version yourself, and use Name this version to label an important one.
• Compare shows what changed between any two versions.
• To roll a blueprint back, select an older version and choose Restore this document from that blueprint's menu.

To download blueprints as Markdown, select Export in the document header and choose Export this blueprint or Export all blueprints as one document.

Agent capabilities

Edit suggestions

The agent can propose structured, reviewable edits to any blueprint. Its edits arrive as tracked suggestions that people with Editor access accept or reject.

Context awareness

The agent has context across:

• All project blueprints
• The codebase index
• Knowledge Base files
• Feature requirements
• Work orders
• Code files linked to each blueprint

This context lets the agent answer questions, generate accurate content, and detect inconsistencies.

Skills and workflows

The agent can:

• Draft and refine blueprint content
• Generate and update Mermaid diagrams
• Review blueprints for gaps, ambiguity, or conflicts
• Answer architectural questions grounded in documentation
• Help synchronize blueprints with requirements and code
• Highlight issues using comments
• Guide structured decision-making workflows

Synchronizing Blueprints with code and requirements

Drift checks are off until you turn them on. There are two separate ways to do that.

Drift automations leave comments on your documents in 8090 Software Factory. Add them from the Recommended section of the Automations page:

• Detect Code Drift runs on code pushes. It reviews the changed files against the code linked to your blueprints, updates those code links, and leaves drift comments on the affected blueprints.
• Sync Blueprints and Requirements runs when a requirement or blueprint changes, and leaves drift comments on the linked blueprint.
• Check Blueprint References runs when a blueprint changes, and leaves drift comments on other blueprints that depend on it.

These automations only leave comments. They don't edit your blueprints or requirements. Drift comments are ordinary comment threads, and their author line shows the automation that wrote them.

Drift Bot reviews pull requests instead. It compares each pull request against your Blueprints and Requirements and posts what it finds on the pull request in GitHub or GitLab. Turn it on for a repository in Settings → Codebase. See Drift Bot.

Best practices

• Treat blueprints as living documents that evolve with the system.
• Use features from Requirements to scope each blueprint section clearly.
• Center blueprints on system behavior and component interactions.
• Turn on the drift automations, Drift Bot, or both, so blueprints stay in sync with requirements and code.
• Include enough detail for confident implementation without locking the design to unnecessary specifics.

Troubleshooting

The agent loses track in a long chat. Start a new chat and bring in only the sections you need, for example by selecting text and choosing Ask agent.

The agent can't update a section from the codebase. Ask it to search the code, then compare what it finds with the blueprint you're editing.

Ready to turn specifications into tasks? Learn about Work Orders.