Why We Start Your Repo at Zero

We've shipped the ActionBoard DevOps Mission skill for Claude Code. It does three things: registers the actions your repo actually runs, classifies each one by what an error would cost, and gates autonomous execution behind demonstrated success across five pipeline stages.

The part that generates the most argument in early installs is what happens on day one. You point it at a repo with eighteen months of green deploys, run the gate check, and every action comes back guided — meaning a human drives and nothing executes on its own.

That's not a bug, and explaining why is the fastest way to explain the whole system.

A year of green builds is one bit per deploy

Your CI history is real evidence. It's just narrower evidence than it looks.

For each deploy, it records one thing: the job exited zero, or it didn't. That tells you something about whether the effect landed. It tells you nothing about the four other things that have to go right for an agent to run unattended:

• Did the orchestrator select the right actions, in the right order, for the stated goal?
• Was the input data current and complete, or did a silently empty result get treated as a valid empty set?
• Was the plan derived from that data correct for the goal, or merely internally coherent while solving an adjacent problem?
• Did anything happen outside the declared scope, and was it logged?

Nobody was scoring those when your pipeline ran. Not because your team was careless — because there was no reason to. A human was in the loop making those judgments, and humans don't emit a score.

So when we backfill your registry from git or CI history, each historical run scores one stage out of five. Not as a penalty. As an accurate representation of what was measured.

What backfill does give you

The backfill script is genuinely useful, just not for the thing people expect:

python scripts/backfill_registry.py --git --since "6 months ago" \
  --out .actionboard/registry.json

It gives you an inventory — the patterns your repo actually runs, grouped by conventional-commit scope or CI workflow. Most teams have never seen this list, and the first reaction is usually surprise at how many deployment paths exist.

It gives you a historical baseline — how often each pattern completed, over what period.

It gives you a starting classification — a keyword heuristic assigns a provisional risk tier. rotate-keys lands at T4. deploy-api lands at T2. The heuristic is a starting point and it will be wrong on anything opaquely named, which is why the install guide budgets an hour of human review per twenty actions.

What it doesn't give you is eligibility. Backfilled runs carry provenance: "backfilled" and are excluded from the clean-run count. That line of code is the whole philosophy.

What clears the gate

An action becomes eligible for autonomous execution when three conditions hold together:

1. It has completed the minimum clean runs for its tier — three for routine, five for standard, ten for elevated
2. Every one of the five stages is at or above threshold across the scoring window — 90% for T1 and T2, 95% for T3
3. The operator has driven the same pattern to completion, and their certified maturity level clears the tier floor

The third condition is the one people push back on hardest, so it's worth defending directly. A success rate measures a pipeline against a goal. A goal the operator can't articulate produces a rate that measures nothing. If your team can't reliably drive the mission by hand, the agent's 90% is noise with a decimal point.

The install cost, stated plainly

Three weeks, roughly:

Week 2 decides whether the installation works. The temptation is to score generously — to mark a stage as passed because the run basically worked. Every generous score becomes a future incident with a paper trail saying the pipeline was fine.

We'd rather tell you about that cost up front than have you find it in week two.

What you get on the other side

A per-stage success record, per action, with an evidence trail that's a by-product of the mechanism rather than a project each audit cycle. That matters more every quarter as AI governance regimes move from interesting to evidenced — and it's the substance behind our ISO/IEC 42001 certification rather than a badge on a page.

You also get a real error rate attached to a real dollar value, which is what any risk-based routing framework actually requires as an input. Most teams try to compute that threshold before they've earned the inputs.