Benchmarks

Definition

A Driftless task is a unit of shaped work. It is not a ticket, a bug report, or an idea — it is work that carries a specification: a description, an initiative context, and one or more acceptance criteria sections. Each acceptance criterion is a Given/When/Then statement (or freeform requirement) with its own status and structured evidence.

A task counts as completed only when all three of the following are true:

• Defined acceptance criteria. The task has acceptance criteria sections before work begins. Work without acceptance criteria is not counted as a completed task.
• Every criterion passed. Each acceptance criterion has reached passed status, backed by a structured evidence reference (a testRef pointing to a unit test, CI run, manual review, pull request, or other reproducible artifact).
• Shipped and human-verified. The work is merged to the main branch via a pull request, and a human has moved the task through user-testing to done. Agents implement and verify against the acceptance criteria, but they do not self-certify done.

Methodology

The benchmark measures how many completed tasks — as defined above — Driftless delivers within a fixed time window. The Driftless task board is the source of truth: it records status transitions, acceptance-criteria statuses, and timestamps for every task.

Included

• Tasks with acceptance criteria sections in which every criterion reached passed.
• Tasks shipped via a pull request merged to main.
• Tasks a human moved from user-testing to done within the 5-day window.

Excluded

• Backlog items and tasks still in todo.
• In-progress and blocked tasks (not yet complete).
• Tasks without acceptance criteria.
• Tasks in user-testing that a human has not yet confirmed — these are not done and are not counted.

Results

The current benchmark result:

The 100-in-5 figure was quoted on Saturday, August 15, 2026 at 12:29 PM. The 787 cumulative completions are recorded on the Driftless task board. Summary evidence — task and acceptance-criteria counts, verification outcomes, and the CI/CD pattern — follows in the next section.

Evidence

Three lines of evidence back the benchmark: task completion counts and acceptance-criteria totals from the task board, the verification gate every completed task must pass, and the CI/CD pattern that ships and verifies each change.

Task completion counts

100 tasks reached done in the 5-day window ending August 15, 2026. 78 of those are directly traceable to pull requests merged to the main branch within the same window. Across those 78 shipped tasks, 286 acceptance criteria sections were defined and passed (an average of about 3.7 per task). The Driftless task board records 787 cumulative completions to date.

Task numbers for the 78 tasks shipped in the window (task numbers are shared; task titles and acceptance-criteria text are omitted):

CI/CD pattern

Every task ships through the same trunk-based, spec-gated pipeline. A pull request to main triggers the quality gates; all must pass before squash-merge, and production deploy gates on the same checks.

• CI — lint-and-typecheck, SAST, unit tests, and image build.
• PR gates — MegaLinter, GitLeaks (secret scanning), Dead Code, Flag Check, and PR Scan run on every pull request.
• Auto-merge — enabled only when every gate is green; the PR is squashed to a single commit on main.
• Deploy — production deploy gates on CI, MegaLinter, and GitLeaks all green on the commit SHA.

Recent pipeline health across 300 runs (August 17–18, 2026): 257 succeeded, 8 failed, 9 cancelled, 26 skipped — 85.7% success.

Verification outcomes

Every completed task passed through a gated status flow: backlog → todo → in-progress → user-testing → done (with blocked as a holding state for unresolved blockers). Each acceptance criterion had to reach passed and carry structured evidence (a testRef pointing to a unit test, CI run, or pull request) before a human moved the task to done. Agents implement and verify against the criteria but cannot self-certify done — the human-in-the-loop user-testing → done transition is the final gate.

Reproducibility

The Driftless workspace — the task board and source repository — is private. External evaluators cannot connect to the task board or re-run the board queries directly, so the benchmark cannot be independently reproduced from outside Driftless. What this page provides instead is the full methodology, the definition of a completed task, the CI/CD pattern, and the current results with their measurement date, so the claim is documented and citable rather than unverifiable marketing copy.

What is recorded

• Status transitions with timestamps for every task.
• Per-criterion statuses and structured evidence (testRefs) for each acceptance criterion.
• Pull-request links tying each shipped task to the merge commit on main.

How a team with access can re-run the count

• List tasks on the Driftless task board filtered to status done over the 5-day window ending August 15, 2026.
• For each task, confirm its acceptance criteria sections are at passed with testRefs evidence.
• Cross-reference each task’s shipping pull request (linked from the task) against the merge history on the main branch.

Context

This benchmark measures one thing: the throughput of shaped work — how many spec’d, acceptance-criteria-gated, shipped-and-verified tasks Driftless can complete in a 5-day window. It is a measure of the delivery system’s capacity to move shaped work to done, not a measure of any other property of the software or the process.

What it measures

• Throughput of shaped work — tasks reaching done (shipped and verified) per 5-day window.

What it does not measure

• Latency — how fast a single task moves from start to done.
• Accuracy — the correctness of any individual change. That is what per-task acceptance criteria verify, not what this benchmark measures.
• User satisfaction — whether the shipped work met a user’s actual need.
• Code-quality trends, business impact, or return on investment.