Command Palette

Search for a command to run...

Arbtr

Command Palette

Search for a command to run...

Domains

Core Concept

Domains cluster related decisions together, making the graph easier to navigate.

What are Domains?

Domains are organizational containers for decisions. They represent architectural areas, team ownership boundaries, or logical groupings.

In the graph view, decisions in the same domain are visually clustered and color-coded, making it easy to see which areas of your architecture are most complex.

Example domains:

DatabaseFrontendAuth & SecurityInfrastructureAPI Design

Why Use Domains?

Visual Clarity

Domains group related nodes in the graph, reducing visual clutter. You can instantly see which architectural area a decision belongs to.

Team Ownership

Map domains to team boundaries. The "Database" domain might be owned by the platform team, while "Frontend" is owned by the product team.

Filtering

Filter the graph or decision list by domain. See only frontend decisions, or only infrastructure decisions.

Briefings

Generate briefings for specific domains. "Give me a summary of all Database decisions from Q4."

Creating and Using Domains

Managing Domains

Domains are managed directly from the graph view:

  1. Open the graph view
  2. Click the Domains button in the controls panel
  3. Add, edit, or delete domains from the dropdown
  4. Each domain gets a name, description, and color

Assigning Decisions to Domains

  1. Open a decision
  2. Click the domain dropdown in the header
  3. Select a domain (or create a new one)

You can also set domains during decision creation or via Magic Paste (if the AI detects a relevant domain).

Best Practices

tip

Start with 3-5 domains

Too many domains creates clutter. Start with high-level areas like "Backend", "Frontend", "Infrastructure", "Security". Add more as needed.
tip

Use consistent colors

Pick a color scheme and stick to it. Blue for data, green for frontend, red for security—whatever makes sense for your team.
i

Domains don't restrict relationships

Decisions in different domains can (and should) have relationships. Cross-domain dependencies are often the most important to track.
!

Avoid domain sprawl

If you have more than 10 domains, consider consolidating. Domains should be broad categories, not specific projects.

Data Model

lib/types.ts
interface Domain {
  id: string
  teamId: string
  name: string
  description?: string
  color: string // Hex color, e.g. "#3b82f6"
  createdAt: Date
  updatedAt: Date
}

interface Decision {
  // ...
  domainId?: string // Optional domain assignment
}
    Domains | Arbtr Docs