Change classes
How telark labels every change cycle by class and severity.
When discovery's cycle detects a delta between the previous and current state of an application, it does not just record "something changed". It runs the delta through a classifier that decides:
- A class — the shape of the change.
- A severity — low / medium / high.
Class plus severity is what makes the change feed something you can triage instead of something you have to skim.
The classes
The discovery service's classifier produces one of these nine classes per change cycle:
| Class | Meaning | Default severity |
|---|---|---|
initial | The application is being recorded for the first time. | low |
topology | The set of workloads composing the application changed (resource added, removed, or re-grouped). | high |
deployment | Image tag rolled forward, chart version bumped, or the equivalent. | medium |
scaling | Replica count moved on a Deployment or StatefulSet. | medium |
config | ConfigMap reference, Secret reference, ports, env vars, service mapping, or ingress rules changed. | low to medium |
resources | The Kubernetes resource set inventoried changed without changing topology. | medium |
drift | The cluster state diverged from what the application's protection plan expects. | medium |
incident | The application's health status degraded — pod crashes, readiness failures, scheduling errors. | high |
recovery | A prior incident state cleared and health is back to normal. | low |
How classification works
The classifier walks a registry of field descriptors. Each
descriptor names a field path on the application record
(images, health.totalReplicas, resources, ports, …) and
maps a non-empty diff at that path to a (class, severity) tuple.
Multiple descriptors can fire on a single cycle. The classifier sets per-class flags as it walks the diff, then picks the final class with this priority:
incidentif a health condition degraded.recoveryif a health condition cleared from a previously degraded state.topologyif the resource set's structure changed.scalingif only replica counts moved.deploymentif only image/chart versions moved.resourcesif only resource definitions moved.configif only configuration references / values moved.driftif the change set looks like an out-of-band edit that contradicts an active protection plan.initialif there is no prior generation.
A change cycle that combines several categories collapses to the single highest-priority class above. The per-field detail is preserved on the cycle's change list, so the dashboard can render all the field-level diffs underneath the headline class.
Severity
Severity is determined alongside class. The descriptor declares a
default; the classifier can elevate severity for unusually large
diffs (e.g. a topology change that affects more than half the
application's resources moves to high).
The dashboard renders severity as a coloured dot on every change row and as a filter chip at the top of the change history panel.
How protection plans use change classes
Protection plans do not drive admission decisions off change
class — admission is governed by the policy template the plan
deploys. But the cycle that records a change does feed the
plan's drift detection: if a protection plan has class=drift
events appearing in its scope, that is a strong signal the cluster
is being mutated out-of-band.
Where it lives in the UI
Change classes drive most of the Application detail page:
- The change history panel — every cycle gets a class badge, a severity dot, and a generation pointer back to the snapshot taken before the change.
- The filters at the top of the change history — pick one or more classes to focus on.
- The enrichment field (if AI enrichment is enabled) renders below the class badge as a short human-readable summary.
Related
- Concepts → Applications and the discovery model
- Concepts → Snapshots and retention
- Features → Snapshots & rollback
- Features → AI enrichment (experimental — disabled by default)