Spaces & Visibility

Spaces are scoped visibility boundaries within a workstream. They control who can see and interact with different categories of information -- internal planning notes, shared collaboration surfaces, and client-owned source material. Every object that can be viewed by external parties is scoped to a Space, and all queries enforce visibility based on Space membership.

Why Spaces Exist

In many professional settings, you need to keep internal reasoning separate from what clients or external collaborators see. A consulting firm discussing risk assessments, an agency drafting strategy, an enterprise team triaging internal bugs -- all need a clear boundary between "what we discuss internally" and "what we share externally."

Spaces provide that boundary at the data layer, not just the UI layer. When content is placed in a Space, the visibility rules are enforced by every query, ensuring that internal content never leaks to external parties accidentally.

The Three Tiers

Each workstream in IAS contains up to three Spaces, one per visibility tier:

Internal

The Internal space is for team-only content. Only internal (RL) users can access it.

• Audience: Internal team members only.
• Ownership: Internal team.
• Use cases: Planning notes, risk assessments, implementation decisions, internal questions (uncertainties), agent triage reasoning, and any context that should not be visible to external collaborators.

Internal space content never appears in views accessible to client users. Decision requests that originate in the Internal space can be forwarded to Shared when client input is needed, but the original internal reasoning stays private.

Shared

The Shared space is the collaboration surface. Both internal team members and external collaborators (clients) can access it.

• Audience: Internal team + client users.
• Ownership: Collaborative.
• Use cases: Client-facing goals and intakes, decision requests that require client input, goal and run status, evidence links (PR URLs, commit SHAs), and any content that forms the "client-safe truth" of delivery.

The Shared space is where most day-to-day collaboration happens. Clients can view status, answer decision requests, and attach context. However, clients cannot create tasks or jobs directly -- they interact through the structured surfaces (intakes, decision requests) that the system provides.

Client

The Client space preserves content owned by the client without modification.

• Audience: Client users (primary), internal team (secondary, read-only by default).
• Ownership: Client.
• Use cases: Jira tickets, Confluence pages, meeting notes provided by the client, uploaded documents, and any other source material where provenance must be preserved.

The Client space enforces a provenance guarantee: when the internal team's write mode is set to read_only for Client spaces, team members can read client-provided materials but cannot modify them. Interpretations or distillations of client material are written to Internal or Shared spaces and linked back to the original item.

Permission Model

Spaces enforce a permission matrix combining user kind (internal vs. client) with space membership roles:

Within each space, individual users have a membership role:

• Owner -- full control, can invite and manage members.
• Editor -- can read and write content.
• Viewer -- read-only access.

The combination of space-level visibility (which user kinds can access the space at all) and role-level permissions (what a specific user can do within the space) provides fine-grained access control.

Write mode for Client spaces

The Client space supports a configurable write mode for internal users. By default, internal users are read_only in Client spaces, preventing accidental mutation of client-owned sources. This can be changed to read_write in workspace settings if your workflow requires internal users to annotate or update client materials directly.

How Spaces Interact with Workstreams

Spaces exist within workstreams. Each workstream represents a unit of engagement or value stream (for example, a client project, a product initiative, or a department). When you create a workstream, the system automatically provisions the three spaces (Internal, Shared, Client) within it.

This means:

• Selecting a workstream in the Console sidebar automatically scopes all views to that workstream's spaces.
• The Briefing aggregates health across all spaces in the selected workstream, with space badges on individual opportunities.
• The Inbox shows decision requests from all spaces you have access to, with visibility indicators.
• Context Lake items are scoped to spaces, so internal knowledge artifacts stay separate from client-visible content.

What Content is Visible in Each Tier

Managing Space Membership

Space membership is managed by space owners through the Console:

1. Navigate to workspace settings.
2. Select the space you want to manage.
3. Invite members by email, specifying their role (owner, editor, viewer) and user kind (internal or client).
4. Update roles for existing members as needed.
5. Remove members who no longer need access.

Only space owners can manage membership. The inviting user must be an internal operator with an owner role on the space and a write-capable role on the workspace.

When inviting a client user to a space, the system verifies that the space tier allows client access (Shared or Client spaces only -- Internal spaces reject client invitations).

Use Cases

Consulting firms and agencies

A consulting firm working with multiple clients creates a workstream per engagement. Internal strategy discussions, risk assessments, and agent reasoning stay in the Internal space. Deliverables, status updates, and client-answerable decision requests go in the Shared space. Client-provided requirements documents and Jira tickets are preserved in the Client space.

Enterprise teams

An enterprise team uses workstreams to separate product initiatives. The Internal space holds technical debt discussions and internal prioritization. The Shared space contains cross-team goals and shared decision-making. The Client space ingests requirements from internal stakeholders who interact through external systems.

Open collaboration

For fully transparent projects where everyone should see everything, all team members can be added to all three spaces. The tier structure still provides organizational value -- distinguishing between team-owned content, collaborative content, and externally-sourced materials -- even when access is unrestricted.

Spaces in the Briefing and Workboard

Both the Briefing and the Workboard are space-aware:

• The Briefing scopes its health summary and opportunities to the spaces of the selected workstream. Opportunities carry space badges (Internal, Shared, Client) and external-space opportunities display safety indicators.
• The Workboard shows items from all spaces the user has access to, with visual cues for items involving external visibility.

This ensures you always know the visibility context of the work you are reviewing or acting on.