# The telemetry contract

> What crosses from your account to LightHouse: operational telemetry, counts and timings, never content.

The **telemetry contract** is the versioned specification of everything your deployment sends to LightHouse, and of how your people read it back. What it allows is operational telemetry: counts, timings, identifiers and costs. It never allows your content.

## The contract and its versions

The contract is versioned: revision 1.15 at the time of writing. Each revision adds to what a deployment may send; nothing valid under an earlier revision becomes invalid. A deployment sends only what the revision it is told LightHouse accepts allows, and holds back anything newer.

## What is sent

Every record is one of a fixed list of types, with only the listed attributes:

| Type                                        | Example attributes                                                             |
| ------------------------------------------- | ------------------------------------------------------------------------------ |
| `model_call`                                | model, backend, input, cached and output tokens, cost, latency, outcome        |
| `run`, `step`                               | pack, card, status, duration, step kind, counts and sizes in and out           |
| `outcome`                                   | what an output was used for, human time saved, whether it was edited           |
| `screening`, `grounding`                    | counts of signals, whether blocked; claims and ungrounded claims               |
| `budget`, `kill`, `preapproval`             | caps and spend; stops and revivals; grants and their use                       |
| `eval`, `release`                           | evaluation metrics and pass or fail; versions and whether they passed the gate |
| `health`, `connector`                       | a component’s status; a connector’s items written, unchanged and removed       |
| `retrieval`, `index_stats`, `evidence`      | search counts; knowledge-base health; claims by evidence tier                  |
| `catalogue`, `models`                       | each agent’s settings; each model’s availability and price                     |
| `deployment`, `infra_cost`, `provider_cost` | profile and wake times; infrastructure and provider cost per day               |

People and runs appear only as keyed hashes. Free text is never allowed, with two exceptions that carry no content: `reason` fields take values from fixed sets, and an agent’s one-line `purpose` is sent only if your pack chooses to publish it.

## What is never sent

Prompts, answers, documents, passages, file names, messages, a card’s instructions, or any value a sender did not take from the fixed list. **Your deployment drops any attribute not on the list, and LightHouse refuses a record that carries one.** A refusal never echoes the value it refused.

## Signed telemetry

Records leave your account through one component, the relay, which signs each request with your deployment’s own Ed25519 key. LightHouse verifies the signature against the key registered for that deployment, refuses a request older than five minutes, and refuses one it has seen before. A record that names another tenant or deployment than its signer is refused.

## Content in place, and opt-in export

Your content stays in your account. When a person opens it in LightHouse, it is read in place through your deployment’s content reader and not kept (see [Knowledge bases](/concepts/knowledge-bases/#read-in-place-never-copied)).

Content export to LightHouse is a separate, opt-in setting, off by default. While it is off, LightHouse refuses any content sent to it (`403 tier_c_disabled`).

See [Data sovereignty](/data-sovereignty/) and [Architecture and trust boundary](/security/architecture/).

Source: https://docs.atlanticagenticlabs.com/concepts/telemetry-contract/