Context Scoping and Workspace Configuration

This guide covers how to structure context across your workspaces so that Catio generates recommendations that are 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.

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 recommendations this workspace produces? If the answer is "it depends which recommendation," the workspace is probably too broad. Recommendations 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 recommendations 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 recommendations 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 recommendations from the start. Filling these in at creation gives Catio a working scope before you generate anything, which means the first batch of recommendations 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 recommendations.

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 recommendations 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 recommendations 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, recommendations 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 recommendation Catio generates includes a Context Summary section that lists the context entries that informed it. See How to Best Utilize Recommendations for where to find it on the full recommendation page. This is your feedback loop for whether your scoping is working.

After generating a batch of recommendations, 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 recommendations. 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.
Recommendations that cite no specific entries or cite only the most generic ones. This means your entries are too vague to anchor a recommendation. 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 recommendation feels off, check the entries it cited before assuming the engine got the architecture wrong.

Treat Context as Ongoing

Context is not a one-time configuration. Priorities shift, compliance requirements change, budgets move, and the architecture itself evolves. Recommendations are only as current as the context driving them.

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. Recommendations generated after the review will reflect the current state of the business rather than the state it was in when the workspace was first configured.