This is Artisan Build’s own real Ballast dashboard.

Commits per month across every repo the team holds, pooled, for the months before this course change against the months after it. Above 1.00× means the team commits more often than it did.

Pooled rather than averaged per repo: a team that moved from one service to another did not slow down, it changed address, and a per-repo rate would read that move as a stall.

Both figures skip a transition buffer around the month you named: a change takes time to show up, and counting the settling weeks as “after” would blunt whatever really happened. That is why this can differ from the plain monthly mean printed under the chart, which averages every month.

It counts activity, not merit. More commits is not better and fewer is not worse.

Lines changed per month either side of the change, pooled across the team and measured over exactly the same window as the commits figure beside it.

These are SOURCE lines: generated and vendored churn is excluded, so a committed lockfile or a regenerated client cannot pass for work.

Both figures skip a transition buffer around the month you named: a change takes time to show up, and counting the settling weeks as “after” would blunt whatever really happened. That is why this can differ from the plain monthly mean printed under the chart, which averages every month.

Lines are a measure of size, not of value. A large deletion and a large addition both count as movement.

New lines per month either side of the change — what was added, as opposed to everything that moved. The gap against the lines figure is work that went into code that already existed.

Both figures skip a transition buffer around the month you named: a change takes time to show up, and counting the settling weeks as “after” would blunt whatever really happened. That is why this can differ from the plain monthly mean printed under the chart, which averages every month.

That gap is information, not a verdict. Lots of new lines can be bloat, and a month spent rewriting can be a refactor that leaves the codebase smaller and healthier.

An em dash means this was not measured, which is not the same as no change. Nothing is inferred and nothing is filled in with a zero.

The mean durability score across the repos that reported each month, before this change against after it — over the same window as the three figures beside it.

Shown as a change in POINTS, not as a multiplier. Durability is a bounded index out of 850, not a rate, so “1.07×” would state something the scale cannot express; the points it moved is the only claim the number supports.

Both figures skip a transition buffer around the month you named: a change takes time to show up, and counting the settling weeks as “after” would blunt whatever really happened. That is why this can differ from the plain monthly mean printed under the chart, which averages every month.

Each repo counts once, whatever its size, and each month averages the repos that reported it — so onboarding a struggling repo can move this without anything having got worse.