Organization settings

Everything in Aletheia belongs to exactly one organization: your AWS connections, repositories, resources, applications, changes, and audit history.

The boundary

Organization scope is enforced on every query, at the data layer, on every endpoint. It is not a filter the interface applies for convenience — there is no request shape that returns another organization’s data.

This is the product’s most important security property, and it is the one thing here that is not configurable. There is no setting that widens it, and no role that crosses it.

What you can change

An administrator can change the organization’s name and its slug.

The slug appears in URLs. Changing it changes those URLs.

Creating one

An organization is created at signup, together with its first user, who becomes its platform administrator. There is no separate provisioning step.

Adding people

People are added by invitation, not by creating accounts for them. An invitation is a single-use link that adds the person to your organization when they accept it.

Multiple organizations

A person’s account belongs to the organization they were created or invited into. Separate organizations are fully separate: separate data, separate members, separate audit history.

If you need production and staging kept apart at that level, two organizations do it. For most teams environments inside one organization are the better fit, because they keep one inventory and one dependency graph.

Where to go next

• Members and invitations to add people.
• Roles and permissions for what they can do.