Evidence types
| Evidence | What you learn from it | Where to inspect it |
|---|---|---|
| Log events | Which grouped log patterns contributed to the issue | Issue detail, Log events |
| Representative logs | Example records that match the finding | Issue detail |
| Fields | Attributes involved in duplication, sensitivity, malformed data, or payload size | Issue detail, log event detail |
| Volume | How often the affected telemetry appears | Issue detail, Log events, Log ingestion |
| Cost | Estimated spend tied to the affected log volume | Cost lane, issue detail |
| Compliance exposure | Sensitive or regulated data detected in telemetry | Compliance lane, issue detail |
| Service ownership | Which service or team owns the affected telemetry | Issue detail, Services |
| Runtime state | Whether a policy is deployed or failing in an execution surface | Policy detail, Edge instances |
Provenance
Provenance identifies where a finding came from. Tero can derive issue context from checks, catalog data, provider inventory, runtime state, or policy activity.Checks
Checks are detector records behind many issues. The Checks screen shows detector inventory for telemetry waste, quality gaps, and policy opportunities across the log estate. Checks can be filtered by All, Cost, or Compliance. Each check can show related open issues and last-run state.Evidence and policy review
Use the evidence to answer four review questions:- Did Tero identify the right telemetry?
- Does the issue matter for cost, compliance, or signal quality?
- Would the recommended policy make the right change?
- Can Tero show where the policy runs and what changed after it ran?