Design your domains

Design the domains that must exist when your environment first starts. The goal is the smallest domain hierarchy that expresses the governance boundaries you need on day one.

Inputs

Before you define the domain tree, identify:

Input	Questions
Operating model	Are you separating clients, regions, business units, treasury desks, compliance teams, or environments?
Ownership	Which team owns root-domain governance?
Oversight	Which parent-domain controls must apply to child domains?
Visibility	Which roles must be able to view domains, users, accounts, transactions, policies, requests, endpoints, and events?
Launch dependency	Which domain boundaries must exist before users and policies can work?

Design decisions

Root domain

Use the root domain for platform-level governance, policy administration, emergency control, and the initial root of trust. Avoid using it as the default place for routine operations if your operating model needs separation.

Launch subdomains

Create a subdomain at genesis when it is required for:

Client or tenant isolation.
Regional or legal-entity separation.
Treasury isolation.
Compliance review or quarantine workflows.
Parent-domain oversight or override.

If a subdomain can be created safely through a governed intent after launch, defer it.

Governing strategy

Choose the governing strategy for each parent domain:

Strategy	Choose when
`ConsiderDescendants`	Parent and child policies should both be considered.
`CoerceDescendants`	Parent policies should override matching child policies.

Use CoerceDescendants only when override is intentional, such as breakglass or compliance enforcement.

Read access

Read access should let each role see the records it needs to approve, investigate, or audit. Review read access for domains, users, accounts, transactions, policies, endpoints, requests, and events.

Genesis domain example

The following example shows the domain portion of a genesis request body. It creates a root domain, one operations subdomain, and one compliance subdomain. The users and policies arrays are intentionally empty here because they are designed in the next two steps.

For the complete genesis request body, see Genesis payload reference. For the post-genesis domain intent shape, see Manage domains.

{
  "rootDomainSetup": {
    "id": "9067d363-6411-498b-a32b-15d230a86706",
    "alias": "Root domain",
    "lock": "Unlocked",
    "governingStrategy": "ConsiderDescendants",
    "permissions": {
      "readAccess": {
        "domains": ["platform-admin", "auditor"],
        "users": ["platform-admin", "auditor"],
        "accounts": ["platform-admin", "auditor"],
        "transactions": ["platform-admin", "auditor"],
        "policies": ["platform-admin", "policy-operator", "auditor"],
        "endpoints": ["platform-admin"],
        "requests": ["platform-admin", "policy-operator", "auditor"],
        "events": ["platform-admin", "auditor"]
      }
    },
    "description": "Root governance domain",
    "customProperties": {},
    "users": [],
    "policies": [],
    "descendants": [
      {
        "id": "1f1e3d9c-f2bf-4a92-a0fa-4a825e70ecb4",
        "alias": "Operations",
        "lock": "Unlocked",
        "governingStrategy": "ConsiderDescendants",
        "permissions": {
          "readAccess": {
            "domains": ["platform-admin", "transaction-operator", "compliance", "auditor"],
            "users": ["platform-admin", "compliance", "auditor"],
            "accounts": ["platform-admin", "transaction-operator", "compliance", "auditor"],
            "transactions": ["platform-admin", "transaction-operator", "compliance", "auditor"],
            "policies": ["platform-admin", "policy-operator", "auditor"],
            "endpoints": ["platform-admin", "transaction-operator", "compliance"],
            "requests": ["platform-admin", "transaction-operator", "compliance", "auditor"],
            "events": ["platform-admin", "compliance", "auditor"]
          }
        },
        "description": "Day-to-day transaction operations",
        "customProperties": {},
        "users": [],
        "policies": [],
        "descendants": []
      },
      {
        "id": "2d37d78f-6f75-4667-93f7-1c6c07d77491",
        "alias": "Compliance",
        "lock": "Unlocked",
        "governingStrategy": "CoerceDescendants",
        "permissions": {
          "readAccess": {
            "domains": ["platform-admin", "compliance", "auditor"],
            "users": ["platform-admin", "compliance", "auditor"],
            "accounts": ["platform-admin", "compliance", "auditor"],
            "transactions": ["platform-admin", "compliance", "auditor"],
            "policies": ["platform-admin", "policy-operator", "compliance", "auditor"],
            "endpoints": ["platform-admin", "compliance"],
            "requests": ["platform-admin", "compliance", "auditor"],
            "events": ["platform-admin", "compliance", "auditor"]
          }
        },
        "description": "Compliance oversight and exception handling",
        "customProperties": {},
        "users": [],
        "policies": [],
        "descendants": []
      }
    ]
  }
}

Output

By the end of this step, you should have:

Root domain owner.
Launch domain tree.
Governing strategy for each parent domain.
Read access by role.
List of deferred domains.

Use the output as input for Plan your first users and Design your policies.