The v-ac-axis-split Skill — Keep Deterministic and Statistical Checks Separate

A verification check either passes by rule or passes by observation. "Status code is 200" has a single correct answer for any given response. "Error rate below 1% over one hour" depends on a measurement window, a sample size, and a threshold. The v-ac-axis-split skill enforces a simple constraint: these two kinds of checks must not live in the same V-AC group.

The skill is loaded during /dr-prd and /dr-plan, before any implementation starts. Its job is to flag mixed V-AC groups and require a split before the specification is finalised.

Why mixing the axes causes problems

Deterministic and statistical checks rely on different evidence chains. A deterministic check — "schema matches XSD," "field is present," "exit code is zero" — is either satisfied or not, with no grey area. A statistical check — "p99 latency under 500ms," "error rate under 1% over 1h" — passes only under certain measurement conditions, and a failure can mean the system is broken or the window was too short.

When the two axes sit in the same group, a post-mortrem on one Datarim pipeline revealed what happens: deterministic checks always passed, statistical checks were the actual uncertainty source, but because they were grouped together the failure was initially classified as a flaky test rather than a design error. The distinction was invisible until the axes were separated.

The split pattern

The procedure has four steps. First, classify each V-AC entry as deterministic (unambiguous rule) or statistical (threshold over a window). Second, if both types exist in the same group, split them into two groups — V-AC-N for deterministic entries and V-AC-M for statistical entries. Third, the statistical group must explicitly cite its measurement window, sample size, and confidence interval. Fourth, the deterministic group must be tied to a bats test, spec assertion, or grep evidence — a monotonic check that produces the same result on every run.

The gate-activation extension

The skill includes a second pattern for a related problem: tasks that ship a new validator gate or promote an existing one from advisory to fail-hard. In that case, /dr-plan Phase 4 must include a dry-run row listing every file that currently fails under the gate's scope. Any file the PRD declares out-of-scope but that falls under the gate's invocation must be either rewritten in the same task or explicitly waived with a documented scope reduction. A gate-activation task that defers files within its own scope is self-blocking: the gate runs against those files at archive time and rejects the archive that activated it.

Read what Datarim is for broader context, or see the related post on the verification-before-completion skill that governs evidence requirements more broadly.