> ## Documentation Index > Fetch the complete documentation index at: https://docs.zespan.com/llms.txt > Use this file to discover all available pages before exploring further. # Instrumentation — what Zespan can see, and who gets each layer > Per stack layer, how much of your analysed traffic was seen through real spans and how much was guessed, who is told when a failure started in each layer, and how to confirm or correct an attribution. **Settings → Instrumentation** shows how well Zespan can see each layer of your stack, who is notified when a failure starts in a layer, and how your confirmations feed back. It explains the [stack-layer attribution](https://docs.zespan.com/reference/stack-layers.md) you see on issues, incidents and traces. ## Layers seen in analysed failures For the failures Zespan has analysed in the range you pick (24 hours, 7 days or 30 days), each row is one layer: | Column | Meaning | | - | - | | **Layer** | Instructions, Retrieval, Memory, Tool, MCP connection, Model, Guardrail, Agent logic, with a one-line note on what records it | | **Seen** | In how many analysed traces the layer was recorded as real spans. *Guessed from tool names in N* counts traces where the layer was only inferred, for example a tool whose name looks like a retriever. *No data in N* counts traces with nothing for the layer | | **What would improve it** | The one step that would turn guesses into observations, with how many attributions it would confirm: *Add retrieval spans to confirm 41 retrieval attributions* | The line above the table says how many layers were seen in every analysed trace. It is a count of coverage, never a grade: a layer you do not use is not a problem. > [!TIP] > > Memory has its own row. Mark memory passages when you build the prompt and Zespan can tell a stale or wrong memory from a retrieval miss. The page is empty, with a plain message, until failures have been analysed. It is also empty for roles that cannot see attributions. ## Gateway and OTLP data Below the table, **Gateway and OTLP data** is the connection test for anything that exports OpenTelemetry traces to Zespan, including AI gateways. Point the exporter at `https://api.zespan.com/v1/traces` with your project key, send one request, then press **Refresh**. Each source that sent data in the last 30 days is a row, with counts for the last 24 hours: | Column | Meaning | | - | - | | **Source** | The gateway Zespan recognised, shown by the product name you configured to send the data, or *OpenTelemetry* for any other exporter. When the label is wrong, set the resource attribute `zespan.gateway`, see [AI gateways](https://docs.zespan.com/sdk/otel-integration.md#ai-gateways). Also: when the last data arrived and how (JSON or Protobuf, gzip) | | **Last 24 hours** | Spans and model calls received | | **Coverage** | The share of model calls that arrived with token counts, a span kind and prompt or answer text, and a one-sentence fix for each problem found | The card reports counts only: it never shows a payload, a header or a key. Until something arrives it says what to do. A test connection from the gateway (for example OpenRouter's **Test connection**) shows as *only a test connection has arrived* until a real request follows. Everyone who can open the project's dashboard can read it. Problems it names: | Message | What to do | | - | - | | Spans arrive without token counts | The gateway may use older attribute names; turn on the compatibility mapping (`OTEL_GENAI_COMPAT`, on by default) or contact us | | Prompt and answer text arrives while prompt capture is off | Zespan drops it before storing it; stop your gateway from sending it if you do not want it to leave your network | | Older attribute names and the mapping is off | Turn the mapping on (self-hosted: `OTEL_GENAI_COMPAT`) | | Only a test connection has arrived | Send one real request through the gateway and refresh | The same data is available as `GET /v1/projects/{id}/otlp-status` in the [API reference](https://docs.zespan.com/api-reference/introduction.md). ## Who gets a failure, by layer Under the table, **Who gets a failure, by layer** lets owners and admins pick, for each layer: | Setting | What it does | | - | - | | **Fix owner role** | Read-only: the role that usually owns a fix in this layer, for example *Data and search* for Retrieval | | **Owner** | A member of your organization who is assigned an incident that started in this layer | | **Alert rule channels** | An existing alert rule of this project. The channels and emails already set on that rule are notified too | How an incident is routed: 1. The layer's **Owner**, when the incident's origin is shown at **Likely** or better, or when it is **Either … or …** and both layers name the same owner 2. Otherwise the owner of the agent in the [agent registry](https://docs.zespan.com/dashboard/agent-registry.md) 3. Otherwise the earliest owner of your organization The alert rule only adds channels; it never replaces the channels of the alert that opened the incident, and they are used for the notification sent when the incident is created. No new secrets are stored: a channel is whatever the alert rule already holds. When a person's account is erased, they are removed from the mapping. > [!NOTE] > > Routing by layer applies only to failures where Zespan shows where they started. A member who has left the organization is skipped, and the table says so. Editors and viewers can read the mapping but not change it. Self-hosted deployments can turn it off with `STACK_LAYER_ROUTING=off`, see [Environment variables](https://docs.zespan.com/platform/environment-variables.md). ## Confirm or correct the layer Under a shown origin on an **Issue** or an **Incident**, Zespan asks *Was it Retrieval?* with **Yes** and **No, it was…**. When two layers fit equally, it asks *Which layer was it?*. * Answering needs permission to manage incidents (owners, admins and editors, on the Team plan and above). Anyone else sees the recorded answer read-only * The question appears only where the origin is shown to you. While attribution is in shadow mode only owners and admins see an origin, so only they can answer, and only they can read the recorded answer * You can change your answer later with **Change answer** * Each item has one current answer. The same answer twice is recorded once What is stored: the item id, the layer Zespan claimed and its tier, the layer you chose, the **role** of the person who answered (for example *admin*), and the time. **No name, no user id, no free text and no trace content** is stored. Answers are kept for two years (730 days from the latest answer), then deleted, to measure how often an attribution is right. They do not change what you see: no answer, and no number of answers, shows or hides a claim on its own. ## Next steps * [Stack layers](https://docs.zespan.com/reference/stack-layers.md): the layers, the tiers and when a claim is shown * [Issues](https://docs.zespan.com/dashboard/issues.md#where-it-started): filter recurring failures by the layer they started in * [Incidents](https://docs.zespan.com/dashboard/incidents.md#where-it-started): who is assigned and notified * [Alerts](https://docs.zespan.com/dashboard/alerts.md): the rules whose channels a layer can reuse, including `mcp_error_rate` * [Traces](https://docs.zespan.com/dashboard/traces.md#where-it-broke): the **Where it broke** row This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.