Skip to content

The telemetry contract

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 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.

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.

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.

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.

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).

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 and Architecture and trust boundary.