diff --git a/packages/apps/tenant/README.md b/packages/apps/tenant/README.md
index f43db79a..cc26c830 100644
--- a/packages/apps/tenant/README.md
+++ b/packages/apps/tenant/README.md
@@ -4,36 +4,55 @@ A tenant is the main unit of security on the platform. The closest analogy would
 
 Tenants can be created recursively and are subject to the following rules:
 
-### Higher-level tenants can access lower-level ones.
+### Tenant naming
 
-Higher-level tenants can view and manage the applications of all their children.
+Tenant names must be alphanumeric.
+Using dashes (`-`) in tenant names is not allowed, unlike with other services.
+This limitation exists to keep consistent naming in tenants, nested tenants, and services deployed in them.
 
-### Each tenant has its own domain
+For example:
 
-By default (unless otherwise specified), it inherits the domain of its parent with a prefix of its name, for example, if the parent had the domain `example.org`, then `tenant-foo` would get the domain `foo.example.org` by default.
+-   The root tenant is named `root`, but internally it's referenced as `tenant-root`.
+-   A nested tenant could be named `foo`, which would result in `tenant-foo` in service names and URLs.
+-   However, a tenant can not be named `foo-bar`, because parsing names such as `tenant-foo-bar` would be ambiguous.
+
+### Unique domains
+
+Each tenant has its own domain.
+By default, (unless otherwise specified), it inherits the domain of its parent with a prefix of its name.
+For example, if the parent had the domain `example.org`, then `tenant-foo` would get the domain `foo.example.org` by default.
 
 Kubernetes clusters created in this tenant namespace would get domains like: `kubernetes-cluster.foo.example.org`
 
 Example:
-```
+```text       
 tenant-root (example.org)
 └── tenant-foo (foo.example.org)
     └── kubernetes-cluster1 (kubernetes-cluster1.foo.example.org)
 ```
 
-### Lower-level tenants can access the cluster services of their parent (provided they do not run their own)
+### Nesting tenants and reusing parent services
 
-Thus, you can create `tenant-u1` with a set of services like `etcd`, `ingress`, `monitoring`. And create another tenant namespace `tenant-u2` inside of `tenant-u1`.
+Tenants can be nested.
+A tenant administrator can create nested tenants using the "Tenant" application from the catalogue.
+
+Higher-level tenants can view and manage the applications of all their children tenants.
+If a tenant does not run their own cluster services, it can access ones of its parent.
+
+For example, you create:
+-   Tenant `tenant-u1` with a set of services like `etcd`, `ingress`, `monitoring`.
+-   Tenant `tenant-u2` nested in `tenant-u1`.
 
 Let's see what will happen when you run Kubernetes and Postgres under `tenant-u2` namespace.
 
-Since `tenant-u2` does not have its own cluster services like `etcd`, `ingress`, and `monitoring`, the applications will use the cluster services of the parent tenant.  
+Since `tenant-u2` does not have its own cluster services like `etcd`, `ingress`, and `monitoring`,
+the applications running in `tenant-u2` will use the cluster services of the parent tenant.
+
 This in turn means:
 
-- The Kubernetes cluster data will be stored in etcd for `tenant-u1`.
-- Access to the cluster will be through the common ingress of `tenant-u1`.
-- Essentially, all metrics will be collected in the monitoring from `tenant-u1`, and only it will have access to them.
-
+-    The Kubernetes cluster data will be stored in `etcd` for `tenant-u1`.
+-    Access to the cluster will be through the common `ingress` of `tenant-u1`.
+-    Essentially, all metrics will be collected in the `monitoring` from `tenant-u1`, and only that tenant will have access to them.
 
 Example:
 ```