Metadata first. Explicit evidence.

What observation records

Operation names, trace/span/session identifiers, relationships, timing, status, versions, explicitly submitted provider/model identity and token counts. Optional events contain static names and codes. Verification checks contain static names and numeric or boolean evidence.

Prompts, arguments, returned payloads, arbitrary state, exception messages and stacks are not captured. Metadata is not automatically free of sensitive information: use static operation names and opaque identifiers, never customer text or secrets. Only instrument code and data you are authorized to observe.

Storage and access

Telemetry is stored in project-scoped Supabase database tables. An authenticated project owner can read it through Traceva's API. Server ingestion keys are write-only, environment-scoped, revocable, and stored only as hashes. Observing your application does not send telemetry to an LLM or execute your tools.

Retention and deletion

New telemetry becomes unreadable seven days after receipt. A scheduled cleanup runs every minute to remove expired live rows, including idle projects. Deleting a project removes its live telemetry and ingestion keys. Existing evaluation reports are separate and unchanged.

Database backups can retain historical data beyond live deletion. The hosted backup/PITR interval and operator restore process must be verified and disclosed before production telemetry collection is enabled. We do not currently promise a verified backup-erasure interval. Local development volumes are not production backups.

What the evidence means

Submitted outcomes are customer-reported evidence, not independent Traceva certification. Missing events, usage and outcomes remain unknown. Successful execution does not prove task success. The optional evaluation demo has a separate flow that can send task data to a model provider; it is not used by the observation SDK.