Plan your first users

Plan the users and role assignments that must exist before the environment starts. These users must be able to satisfy every policy workflow that is required at launch.

Use the domain model from Design your domains and list:

• Roles that create launch-critical intents.
• Roles that approve launch-critical intents.
• Roles that need read access.
• Bot users required for automated workflows.
• Emergency or recovery users.

Start with role responsibilities, not names.

Choose names that operators will understand. Role names are strings that you can define whenever you need them, but users receive those roles only through genesis or a governed user intent after launch. Use the same role names in users, policies, and domain read access.

For each policy workflow, confirm that the launch users can satisfy quorum.

Do not rely on users that can only be created after launch to satisfy policies that must work at launch.

Genesis users are the initial root of trust. They cannot be deleted, so choose them carefully. They can be locked later, but the launch model should not depend on a single person or a single credential.

Recommended checks:

• At least two human users for critical human roles.
• No single user can complete a high-risk workflow alone.
• Bot users are limited to the workflows they need.
• Emergency users are independent from routine operators where possible.
• Role names match the policy workflows exactly.

The following example shows users as they appear inside a genesis domain's users array. Genesis users do not include a type field because they are embedded in the genesis domain setup, not submitted as v0_CreateUser intents. For post-genesis user creation, see Manage users and roles.

[
  {
    "id": "e1fe3431-f899-427b-9e67-a75fb9fe5e57",
    "alias": "platform-admin-1@example.com",
    "publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEe32vCCfM0LXmT6VuZo4AykiZ8YfBMB92nKNX8K+PRhN7/qPhILzGlOv/7kDyefTxHSrytXG28OB0cPwErlHgyQ==",
    "roles": ["platform-admin", "policy-operator"],
    "loginIds": [
      {
        "id": "platform-admin-1@example.com",
        "providerId": "harmonize"
      }
    ],
    "lock": "Unlocked",
    "description": "Genesis platform administrator",
    "customProperties": {
      "userType": "human"
    }
  },
  {
    "id": "7bf37a53-51a5-48da-b7d1-c2fa05bd3f14",
    "alias": "compliance-1@example.com",
    "publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAET1BnSIvToEO6r5BMmaG+O3GL0/A7JilzCdmJ3trIWIsXDuv8jAcGizraMouqWIHTx2hi3rxoH7eABURbfSSryw==",
    "roles": ["compliance"],
    "loginIds": [
      {
        "id": "compliance-1@example.com",
        "providerId": "harmonize"
      }
    ],
    "lock": "Unlocked",
    "description": "Genesis compliance approver",
    "customProperties": {
      "userType": "human"
    }
  }
]

Use the same role strings in:

• The roles array for each user.
• Domain read access permissions.
• Policy workflow steps.
• Policy conditions that check author or target roles.

By the end of this step, you should have:

• First-user list.
• Role assignments by domain.
• Quorum coverage table.
• Bot user list.
• Emergency user list.

Use the output as input for Design your policies.