onboarding: setting contextual boundaries

## What Are Contextual Boundaries?

Think of contextual boundaries not as walls, but as intelligent, dynamic rulesets that define the perimeter of a life domain. They are the digital equivalent of having different rooms in a house. You are the same person whether you're in the kitchen or the office, but the room's function, tools, and atmosphere are completely different.

A boundary is an invisible container that governs four things within a specific context (e.g., "Work," "Family," "Deep Learning"):

1. Information Access: It filters what you see. In the "Work" context, your file browser shows company folders and your work contacts are prioritized. Switch to the "Family" context, and you see family photo albums and personal contacts. The work files don't disappear; they just become invisible and inaccessible.
2. Notification Flow: It manages interruptions. The "Work" boundary might allow notifications from Slack and your boss. The "Deep Learning" boundary would block them, but allow a notification from your research app.
3. Tool Configuration: It changes how your apps behave. The same Create verb might open a document in Craft. In the "Work" context, it defaults to saving in a shared team folder. In the "Personal" context, it saves to your private journal.
4. Active Persona: It selects the right "you" for the job. When you send an email from the "Work" context, it automatically uses your professional signature and alias.

## How Are They Managed?

The management is a partnership between you (the Architect) and the OS (the automated System). This avoids tedious manual setup and aligns with the S1/S2 handoff.

• You, the Architect (The S2 Intent): You perform the initial, high-level act of defining your domains. This is a simple, one-time setup: "Create a domain called 'Work'," "Create a domain called 'Studio'." You can then link key assets to them, like a specific email account, a core folder, or key people.
• Kairos, the OS (The S1 Automation): The OS handles the real-time, automatic enforcement of the boundaries. It switches between them based on simple triggers, so you don't have to think about it.

Triggers for activating a boundary:

• Explicit: You manually select a domain from your Kairos map. "I am now entering my 'Studio' context."
• Implicit (Learned & Automated):
• Time-based: At 9:00 AM on weekdays, automatically activate the "Work" boundary.
• Location-based: When you arrive at your office or studio, it activates the relevant boundary.
• Event-based: When a calendar event titled "Design Review" begins, the OS activates the "Work" context and might even pre-load the relevant project files.
• Person-based: If your partner calls, the OS can temporarily surface the "Family" context, even if you are in "Work" mode.

## How to Best Use Them

Using contextual boundaries effectively is the key to achieving cognitive liberation. It’s about moving from a reactive state to an architectural one.

1. For Deep Focus & Flow 🧘

The most powerful use is to create cognitive sanctuaries. When you activate your "Create" or "Deep Learning" boundary, you are giving the OS permission to be ruthless in protecting your attention. It's a pre-commitment to focus. The boundary doesn't just minimize distractions; it makes them entirely non-existent for a set period, allowing you to achieve flow states that are impossible in a notification-rich environment.

2. For Seamless & Present Transitions ↔️

The cognitive cost of switching from "work mode" to "home mode" is high. It often involves a lingering sense of anxiety or unfinished business. Contextual boundaries make this transition clean and instantaneous. By switching from your "Work" to your "Family" domain, you aren't just changing apps; you are changing your entire digital environment. This allows you to be fully present in the current context, knowing the other is safely contained and will be there when you return.

3. For an Integrated, Authentic Self 👤

This is the highest-level benefit. We are often forced to perform a rigid "work persona" and a "personal persona." Contextual boundaries allow you to be one integrated person who simply reveals the appropriate facets of yourself in different situations. You don't have to police yourself; the system handles the context. This reduces the mental energy spent on "code-switching" and allows for a more authentic and less fragmented sense of self.

Yes, it is appropriate, but not by forcing the user to name their domains after the quadrants. That would be too abstract and restrictive.

The framework should be used as an underlying, invisible organizing principle that the user's natural domains are mapped onto. The approach should be a two-layer system that offers both personalization and power.

## The Principle: Mirror the User's Mind

The goal is to create a tool that feels like an extension of the user's own mind. People do not think of their lives in terms of abstract quadrants like "Public • Other." They think in concrete, semantic terms:

• "My Job at Acme Corp"
• "My Family"
• "My Studio Project"
• "My Health & Fitness"

Forcing the user to adopt your philosophical labels during setup would create immediate cognitive friction. Instead, the system should allow the user to define their life in their own words first.

## The Solution: A Two-Layer Approach

The most effective way to structure the setup is to separate the user's personal map from the system's functional compass.

Layer 1: The User's Map (Semantic & Concrete)

This is the initial setup you described. The user, as the architect, creates domains using their own natural language. This is the "what."

• Create Domain: "Acme Job"
• Create Domain: "Novel Writing"
• Create Domain: "Family Life"

This step ensures the system is a direct mirror of the user's reality.

Layer 2: The Kairos Compass (Functional & Abstract)

This is the four-quadrant framework. It’s the OS's underlying understanding of intent. This is the "why."

## The "Onboarding Bridge": Connecting the Layers

During the setup for each new domain, the OS asks one simple, clarifying question to connect the user's concrete domain (Layer 1) to the system's abstract compass (Layer 2).

Example Workflow:

1. User Action: Creates domain: "Acme Job"
2. Kairos OS Asks: "What is the primary purpose of this domain?"
• A) To build or produce things? (> maps to Create)
• B) To collaborate and communicate with others? (> maps to Connect)
• C) To learn, plan, and prepare? (> maps to Cultivate)
• D) To analyze and process information? (> maps to Synthesize)
3. User Selection: The user is a manager, so their primary function is communication. They select (B).

Now, the system knows that the user's concrete domain "Acme Job" has the functional property of Connect. It can automatically apply the correct rules for notifications, tool suggestions, and boundary management without the user ever having to think in terms of quadrants.

Another Example:

• Domain: "Novel Writing"
• Primary Purpose?: (A) To build or produce things.
• Result: This domain is tagged with the Create property. Kairos now knows to enforce a "cognitive firewall" when this domain is active, blocking notifications from the "Acme Job" (Connect) domain.

This approach provides the best of both worlds:

• Intuitive Personalization: The user defines their life in their own terms.
• Systemic Power: The OS uses the underlying framework to automate and orchestrate actions intelligently.