Burn-in Baseline

When a feature ships without any pre-release baseline data, VEKTIS uses burn-in to build one from your first few post-release measurements. Once enough data has accumulated, impact scoring switches on and your dev item starts behaving like any other.

How burn-in works

Stage	What’s happening	What you see
Collecting	Recording the first few post-release measurements as the baseline	”Establishing baseline from post-release data”
Complete	Baseline statistics computed from those measurements	Impact scores start appearing on the next measurement
Steady state	New measurements scored against the burn-in baseline	Standard impact zones (Significant / Confirmed / Signal)

When burn-in kicks in

Burn-in only applies when a dev item has zero pre-release baseline measurements. If you’ve recorded even one baseline before release, normal impact scoring runs from the very first post-release measurement.

Why pre-release baselines beat burn-in

Pre-release data captures the metric before the feature could possibly affect it — a true “before” picture. Burn-in measurements come after release, so they may already include some of the feature’s effect, which can make later changes look smaller than they really are.

Tip

If you can capture even rough baseline data before shipping — including indirect proxies like time-to-complete-a-task — do that. Burn-in is a safety net, not a default.

Practical guidance

You see	What to do
”Establishing baseline” badge	Keep recording measurements at a regular cadence — impact scores will appear once enough data is collected
Burn-in complete, impact scores arriving	Treat it like any other dev item — read the impact zone and decide
No pre-release data and the feature hasn’t shipped yet	Add at least one baseline measurement now; you’ll get cleaner scoring than burn-in can offer
Already in burn-in but you have historical data	Add it as a baseline anyway — VEKTIS will use it on the next score calculation