> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usetero.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How Tero compares

> Where telemetry control fits in your stack

Tero is a control plane for telemetry policy. It sits above the systems that collect, store, route, and execute telemetry changes.

Tero owns one loop across those systems: find telemetry issues a policy can fix, present evidence for review, and track policy runtime impact.

| Work you already do                          | Existing systems answer                          | Tero answers                                                                                               |
| -------------------------------------------- | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- |
| Store, search, and visualize telemetry       | What happened in production?                     | Which telemetry creates cost, compliance, or signal-quality issues, and what policy should address it?     |
| Route, buffer, enrich, and forward telemetry | Where should telemetry go next?                  | Which policy should run, where should it run, and did the runtime apply it?                                |
| Reduce observability spend                   | Which account, team, or service spent money?     | Which log events caused the spend, what evidence supports action, and which policy can reduce it?          |
| Control sensitive telemetry                  | Which controls and risks does the company track? | Which telemetry exposed sensitive data, what policy can remove it, and did exposure decrease after action? |

## Observability platforms

Datadog and Splunk store telemetry, run queries, power dashboards, and expose provider-specific controls. Tero connects to them for evidence, catalog context, usage, and provider actions.

Your observability provider remains the source of record for its data and configuration. Tero adds a review layer that ties costly or sensitive log events to a policy and confirms the change took effect.

Provider actions stay provider-specific. In Datadog, that can mean exclusion filters or pipelines. In Splunk, that can mean ingest actions. Tero keeps the policy review and impact model consistent across providers.

## Pipelines and collectors

Collectors and pipelines move telemetry. They route, buffer, enrich, filter, and forward data to the next destination.

Tero owns the policy control loop above those runtimes. A policy starts from an issue with evidence attached. Your team reviews it and deploys it through the runtime you choose; the runtime executes the change while Tero tracks policy state and impact.

Use the [Edge](/edge/overview) docs when you want policies to run before telemetry leaves your infrastructure.

## Cost tools

Cost tools show spend. They help you allocate cost by account, service, product line, or team.

Tero shows the telemetry issue behind the spend. The Cost lane links service-level log cost to open issues and policy recommendations. A reviewer does the work: opens the issue, checks the evidence, and approves or rejects the policy.

## Security and compliance tools

Security and compliance tools define controls, detect exposure, and support audit work.

Tero focuses on telemetry policy issues that create compliance exposure, such as sensitive fields in log events. The Compliance lane groups affected services and links into issues with evidence, recommended policy action, and status.

Tero feeds your control process. Your security or compliance system remains the place where your company owns risk acceptance, audit evidence, and security operations.

## Policy repositories

Git gives policies review, version history, and auditability. Tero can sync policies to repositories when your workflow needs that control.

The policy object still starts from evidence. A repository can store the policy, but Tero keeps the relationship between issue, policy, runtime deployment, and impact visible.