Workspace Scoping with Blueprints, Bookmarks, and Plans

This guide covers how to structure context across your workspaces and use blueprints, bookmarks, and plans together so Catio generates and operationalizes architecture changes specific to the part of your business you actually want to improve. If you are new to adding context, start with Adding Context for the mechanics of uploading files and entering requirements. This guide assumes you already know how to add context and focuses on the decisions that come before and after that step.

How These Pieces Work Together

Context, blueprints, bookmarks, and plans form a connected workflow:

• Workspace Context defines what Catio knows about your business: technical requirements, business goals, and constraints.
• Blueprints are the architectural changes Catio generates based on that context.
• Bookmarks are a curated collection of blueprints you want to keep accessible for reference, review, or future planning.
• Plans are the operational grouping of blueprints actively under consideration or scheduled for execution.

Bookmarks and plans function independently. Bookmarking a blueprint does not add it to a plan, and adding a blueprint to a plan does not bookmark it. Each serves a different stage of the lifecycle: bookmarks for curation, plans for execution.

The quality of every downstream step depends on how well-scoped the workspace is at the top. Sharp context produces sharp blueprints, which makes bookmarks and plans meaningful rather than cluttered.

Start with the Workspace Boundary

Context scoping begins with the workspace itself, not with the entries inside it. A workspace should map to a specific system, product, team, or business function that you want to evaluate as a unit. If the workspace spans too much, no amount of careful context entry will tighten the output, because Catio will be evaluating a boundary that doesn't match a real decision-making scope in your business.

Before adding context to a workspace, ask:

• Who would own the blueprints this workspace produces? If the answer is "it depends which blueprint," the workspace is probably too broad. Blueprints that span multiple teams tend to stall because no single owner can act on them.
• What decision is this workspace meant to support? A workspace scoped to support a specific decision (e.g., "modernize the payments platform," "prepare identity services for SOC 2") will produce sharper blueprints than one scoped to "our infrastructure."
• Does one set of constraints apply across everything in the workspace? If the budget, compliance requirements, or SLAs differ across parts of the workspace, you are probably looking at two workspaces, not one.

When a workspace boundary is wrong, the symptom is usually blueprints that feel contradictory or that cite requirements from one part of the business while targeting components that belong to another. The fix is to split the workspace before continuing to add context.

Scope the Workspace at Creation or Later

You can establish workspace scope at two points: during workspace creation, or by editing the workspace afterward.

The workspace creation flow captures optional fields, including objectives and in-scope systems, that pre-apply context to inform Archie chats and blueprints from the start. Filling these in at creation gives Catio a working scope before you generate anything, which means the first batch of blueprints is anchored to the decision the workspace is meant to support rather than to the architecture in general.

If you skip these fields at creation, you can add or refine the same information later by editing the workspace. Either path produces the same effect on downstream blueprints.

Use Saved Views in Stacks for Architecture-Level Scoping

Workspace boundaries and context entries scope what Catio knows about your business. Saved views in Stacks scope which parts of your architecture Catio is evaluating against that knowledge.

For large or complex architectures, create a custom, filtered view in Stacks that isolates the components relevant to the decision at hand, then tag that saved view when generating blueprints or interacting with Archie. This narrows the architectural surface Catio considers without requiring you to break the workspace apart.

Use this when the workspace boundary is correct but the architecture inside it is broad enough that blueprints are spreading thin across components you don't currently care about.

Structure Context by Requirement Type

Context in Catio is organized by category (Infrastructure, Performance, Security, Finance, Legal, and so on). See Adding Context for the full list. Categories are how Catio routes context, but they are not how you should think about what's missing from your workspace.

A more useful framing is to think in three requirement types and confirm your workspace has coverage across all three:

Technical requirements describe how your architecture must operate. What regions, what latency targets, what availability targets, what tooling is already in place.

Example: "Primary production environment runs AWS us-east-1 with disaster recovery in us-west-2. API response times must remain under 200ms at P95 latency."

Business requirements describe why the architecture exists and what it must support. What the architecture is trying to achieve and for whom.

Example: "Platform must achieve 99.9% availability to meet enterprise client SLA commitments. Q2 priority is reducing public-facing attack surface to support the ongoing SOC 2 audit."

Constraint requirements describe the limits the architecture must operate within. Budget, headcount, compliance boundaries, change windows.

Example: "Annual infrastructure spend cannot exceed $600K including licensing. Engineering headcount capped at 20 FTEs through fiscal year."

Workspaces commonly skew heavily toward technical requirements and under-represent the other two. When that happens, blueprints describe what's technically possible without reflecting what's actually viable for the business. Cover all three types and Catio can evaluate tradeoffs the way your team would.

Validate Scoping Through the Context Summary

Every blueprint Catio generates includes a Context Summary section that lists the context entries that informed it. This is your feedback loop for whether your scoping is working.

After generating a batch of blueprints, scan the Context Summary on each one and look for three patterns:

• Entries cited that do not apply to the workspace. This means the workspace is inheriting context from too broad a scope, or context from another part of the business has ended up in this workspace by mistake. Remove or re-scope the offending entries.
• The same one or two entries cited repeatedly across blueprints. This means your context is thin. Catio is evaluating your architecture against whatever requirements it has, even if that's a narrow slice. Identify which of the three requirement types (technical, business, constraint) are under-represented and add entries to fill the gap.
• Blueprints that cite no specific entries or cite only the most generic ones. This means your entries are too vague to anchor a blueprint. Rewrite them to be specific and measurable.

The Context Summary is the fastest way to distinguish a context problem from an architecture problem. If a blueprint feels off, check the entries it cited before assuming the engine got the architecture wrong.

Curate with Bookmarks Before Committing to Plans

Once blueprints are generating against a well-scoped workspace, use bookmarks and plans to manage what happens next. The two are deliberately separate stages.

Bookmarks are for the blueprints you want to keep visible without committing to them yet. Use them to:

• Maintain reference access to specific blueprints without repeated searches.
• Build a collection of high-impact architectural changes for team review.
• Hold blueprints that are promising but need validation, owner identification, or stakeholder alignment before moving forward.

Plans are for the blueprints you have decided to act on. Use them to:

• Group blueprints that belong to the same initiative or planning cycle.
• Track what's actively under consideration or scheduled for execution.
• Communicate scope to the team responsible for delivery.

A useful pattern is to bookmark broadly during review, then promote only the blueprints with clear ownership and intent into a plan. This keeps plans lean and actionable while bookmarks remain a working space for evaluation.

When a plan starts accumulating blueprints that have lost momentum, move them back to bookmarks or remove them entirely. Plans lose their value as a coordination tool when they become a catch-all.

Treat Context as Ongoing

Context is not a one-time configuration. Priorities shift, compliance requirements change, budgets move, and the architecture itself evolves. Blueprints are only as current as the context driving them, and the plans built on top of those blueprints inherit that same dependency.

A reasonable cadence is to review the context in each workspace at the start of a planning cycle (quarterly for most teams) and after any material change: a new compliance requirement, a budget revision, a leadership change, a significant architecture migration. Remove entries that no longer apply and add entries for anything newly relevant. Blueprints generated after the review will reflect the current state of the business, and the plans you build from them will reflect what your team can actually deliver against that state.