---
title: "Project routing"
description: "Reference for selecting Judgment projects by name or ID and separating deployment environments safely."
seo:
  title: "Judgment Project Routing Reference"
  description: "Select Judgment projects by name or ID, separate deployment environments, and verify routing at startup."
---

Every trace, SDK request, and JQL query belongs to one organization and one
project. Judgeval clients select a project by name. Direct OTLP export selects
it by ID.

## Selection methods

| Client | Project selector | Where it is sent |
| --- | --- | --- |
| Python `Tracer` or `Judgeval` | `project_name="my-project"` | SDK initialization or client construction |
| TypeScript `Tracer` or `Judgeval` | `projectName: "my-project"` | SDK initialization or client construction |
| Direct OTLP/HTTP | `X-Project-Id: <JUDGMENT_PROJECT_ID>` | Request header on every export |
| Judgment MCP | `project_id` | Tool argument after selecting an organization |

For direct OTLP, copy the project ID from the project URL or use Command Menu
to find the project ID shortcut. Do not substitute a project name in the
`X-Project-Id` header.

## Environment boundaries

Use separate projects for local development, tests, staging, and production.
Derive an explicit project name from the deployment environment instead of
falling back to a generic name:

```python
import os
from judgeval import Tracer

environment = os.environ["APP_ENV"]
project_name = f"{environment} - my-agent"

Tracer.init(project_name=project_name)
```

In TypeScript, pass the computed value as `projectName` to the single
`Tracer.init()` call.

> **Silent routing mistakes look healthy**
>
> A missing project name can leave monitoring disabled. A guessed or fallback
> name can route traces to an unintended project. The application may still run
> normally in both cases.

## Distributed services

All services contributing spans to one distributed trace must export to the
same Judgment organization and project. Distinguish services with resource
attributes such as `service.name`, not with separate projects. See
[Trace conventions](/documentation/reference/trace-conventions).

Use a new project for an environment boundary, not for an internal service
boundary. Use [Distributed tracing](/documentation/tracing/distributed) to
carry one live request between services.

## Startup verification

At startup, log the selected project name or ID and deployment environment.
Never log the API key. Then send one real trace and verify:

1. The trace appears in the intended organization, project, and environment.
2. The expected project was selected before the root span started.
3. Every service in one distributed trace used the same project.
4. Local and test traffic does not appear in the production project.

Initialization logs prove only what configuration the process attempted to
use. The received trace in Judgment is the routing proof.

## Related pages

- [Authentication](/documentation/reference/authentication)
- [Instrument your agent](/documentation/tracing/instrumentation)
- [Direct OTEL](/documentation/integrations/tracing-providers/direct-otel)