> ## Documentation Index > Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt > Use this file to discover all available pages before exploring further. # Projects, services and environments > How aiAxonIQ groups your telemetry: services come from service.name, environments from deployment.environment, and projects organize APM views — none of them is an access boundary. aiAxonIQ has four words for "a part of my system": **organization**, **project**, **service** and **environment**. They are easy to confuse, and they do very different jobs. Only one of them — the organization — decides who can see what. | Concept | Where it comes from | What it controls | | :--------------- | :------------------------------------------------------------------ | :---------------------------------------------------------------- | | **Organization** | Created for you, and chosen by the license key on every request | Isolation. Who can see the data, and which account it belongs to. | | **Service** | The `service.name` resource attribute your telemetry carries | Per-service views, the service map, most alert scopes. | | **Environment** | The `deployment.environment` resource attribute | Telling production apart from staging inside one organization. | | **Project** | Created in APM, or registered automatically where that is turned on | Which services an APM page shows together. | ## Organizations: the only boundary Everything you send belongs to exactly one organization, and the license key on the request decides which. Users, license keys, dashboards and alert rules all belong to an organization too. Nothing narrower — not a project, not an environment — keeps one group of people from reading another group's data. **If you need separation for access control, you need two organizations.** Projects and environments are for organizing what you look at, not for hiding it. See [Organizations and multi-tenancy](/concepts/organizations). ## Services: named by your telemetry A **service** is whatever reports the same `service.name`. There is no service to create or register: a service appears as soon as telemetry arrives under a new name, and the **Get started** page names the services it has seen. ```bash theme={null} OTEL_SERVICE_NAME=checkout-api ``` **An unset `service.name` becomes `unknown_service`.** Every service that forgets it merges into one entry that looks large and means nothing. Set it first. See [Resource attributes](/send-data/otel/resource-attributes). Use the **same** service name in every environment. `checkout-api` in staging and `checkout-api` in production are one service in two environments; `checkout-api-staging` and `checkout-api-prod` are two services that can never be compared. ## Environments: an attribute, not a container An **environment** is the value of the `deployment.environment` resource attribute. aiAxonIQ also reads the newer spelling, `deployment.environment.name`, so either works. ```bash theme={null} OTEL_RESOURCE_ATTRIBUTES=deployment.environment=production ``` There is nothing to create: the value arrives on your telemetry, and the product picks it up. The **APM → Service map** has an environment filter built from the values your traces carry, and you can search logs on the attribute — see [Searching logs](/guides/logs/search). **Without it, staging and production are the same service.** Every chart shows the sum of the two, and a staging failure looks like a production one. The fix is one attribute on the sender. You cannot add it later to data that has already arrived. ### The environment you picked on Get started is a different thing When you set up your account, **Get started** asks how you are sending data — a Linux host, Docker, Kubernetes, an OpenTelemetry SDK or an OpenTelemetry Collector. That choice decides which install instructions and wording you see. It is **not** `deployment.environment`: it does not label your telemetry, and it does not separate one environment from another. ## Projects: grouping services in APM A **project** is a named group of services that the APM pages show together. You find them under **APM → Projects**. A project shows the telemetry of: * the service whose `service.name` is exactly the project's name — no mapping needed, and * any other services you attach to it in the project's **Settings**, under **Services**. That second option is for a project named after a business capability — `checkout` — that is made up of services with other names. Each service can belong to only one project. In **APM → Projects**, select **Add APM project** and give it the name your service reports as its `service.name`. Creating a project needs the **Editor** role. Open the project's **Settings** and add the other service names under **Services**. A new project is empty until one of its services sends traces in the selected time range. If it stays empty, compare the project name with the exact `service.name` your telemetry carries — the match is exact. **Some organizations have projects created automatically.** Where this is turned on, a service that sends traces under a name no project claims gets a project of its own on its first span. Whether it is on depends on your deployment. ### What a project does not do **A project is not an access boundary.** Everyone in the organization can see every project. Rotating a project's keys and deleting a project need the **Admin** role. * **It does not change how you send OpenTelemetry data.** OTLP is always sent with a license key, which belongs to the organization, not to a project. A project's own keys are used by the browser agent for [real user monitoring](/guides/rum/overview) and to upload [source maps](/guides/rum/source-maps). * **It does not narrow logs or metrics.** Logs and metrics are organization-wide. Projects group trace-based APM views. * **Deleting a project deletes no telemetry.** The data stays, and the project simply stops grouping it. ## How they fit together ```text theme={null} Organization ← license keys, users, roles, plan: the boundary ├─ Environment ← deployment.environment on each record │ └─ Service ← service.name on each record └─ Project ← an APM grouping of one or more service names ``` An environment and a project cut across each other. A project groups services by name; it does not know about environments. To look at one project in one environment, use an environment filter where the page offers one, such as the service map. ## Next How `service.name` and `trace_id` connect logs, metrics and traces. Setting `service.name` and `deployment.environment`, and naming services well. Isolation, membership, and when to use a second organization.