v1.0.3

Telemetry & Privacy

Optional product telemetry uses small, aggregated, allow-listed snapshots. It is separate from the operational logs, metrics, and traces that your deployment owns.

What telemetry is

Product telemetry helps the maintainers understand anonymous OSS adoption and broad workload patterns. It is not billing, clickstream tracking, user analytics, a way to inspect your agent runs, or a replacement for operational observability.

This is deliberately different from observability. Your deployment controls its logs, metrics, and OpenTelemetry exporters. Product telemetry uses a separate, privacy-reviewed outbound path with a fixed schema.

Defaults and disabling

The default mode is standard: essential installation telemetry is enabled, while product analytics and performance research are disabled. The bundled exporter defaults tonone, so a new installation makes no outbound telemetry request until an operator deliberately configures an exporter.

bash

# Disable all outbound product telemetry
AI_GOVERNANCE_TELEMETRY_MODE=disabled

Disabled mode sends nothing, clears pending snapshots, and needs no exporter configuration. It is appropriate for air-gapped or policy-restricted deployments. The same setting can be managed through the Settings control plane when the operator has permission.

What can leave a deployment

A snapshot is aggregated locally by time period and has a versioned, allow-listed shape. It contains a randomly generated installation ID, release version, time range, category, and simple counters or fixed duration buckets. The installation ID is not a tenant, organization, user, host, IP address, MAC address, or customer identifier.

json

{
  "schema_version": "1",
  "installation_id": "random local UUID",
  "ai_governance_version": "release version",
  "period_start": "timestamp",
  "period_end": "timestamp",
  "category": "ESSENTIAL | PRODUCT_ANALYTICS | PERFORMANCE_RESEARCH",
  "metrics": { "named_counter": 0 },
  "distributions": { "named_duration": { "fixed_bucket": 0 } }
}

The allow-list excludes prompts, responses, datasets, evidence, policies, ontology content, model inputs or outputs, names, emails, tenant or project identifiers, customer labels, secrets, tokens, paths, URLs, stack traces, and arbitrary metadata. Payloads are validated immediately before delivery.

An exporter is an explicit decision

The built-in optional exporter is PostHog and requires an HTTPS endpoint plus a secret reference such as env://POSTHOG_API_KEY. Never put a plaintext exporter key in a runtime setting.

Inspect before sending

Operators with Settings read access can inspect the current telemetry state and the exact sanitized snapshots before any delivery occurs:

GET /api/v1/telemetry/status shows mode, enabled categories, exporter state, and health.
GET /api/v1/telemetry/preview returns the read-only sanitized payload preview.

Preview does not queue or transmit anything. Use it as part of a privacy or deployment review.

Reliability and boundaries

Delivery happens in a low-priority background path. Pending snapshots and retry attempts are bounded, and an exporter failure does not interrupt governance work. Product telemetry must never become a dependency for an API request, a job worker, or an agent runtime.

For database tracing specifically, keep PostgreSQL spans low-cardinality and never emit raw SQL parameters, tenant identifiers, evidence references, credentials, or protected content. Prefer a safe operation summary such as SELECT causal_audit over query text.