Score a verification task

A verification task turns “this looks fine” into a number. It carries a rubric, a subject, and a passing score, and it resolves into one of three verdicts that other work reacts to.

This page uses SUM-16, the check on the Summitline route builder’s acceptance criteria that Maya holds. A failing nightly check raises no verification: it raises a fix task on the work that broke.

What a verification carries

• A subject, the thing being checked. It points at a field on another task, an artifact, or something outside the workspace.
• A rubric snapshot: the criteria, each with a weight, copied onto the task when it was created. The snapshot is why a score stays meaningful after the rubric is later edited.
• A passing score, the weighted total the subject has to reach.

The lifecycle

State	Means
pending	Created, not started
scoring	Being worked through
passed	Met the bar
needs revision	Did not meet the bar, but the work is worth another pass
failed	Did not meet the bar, and it is not worth another pass

Who can submit a verdict

A verdict is one named person’s signature, so the platform is strict about whose it is.

• The person the task is assigned to can submit it, and so can any workspace admin. That is by person, not by position: holding the right job title is not enough, and needing no title is not a problem.
• The person who asked for the work, or whose agent run produced it, cannot sign it off. Someone else has to look at it. The one exception is a workspace where nobody else could: if you are the only person who can decide it, you can, and the decision is recorded as yours alone.

Anyone else who tries is refused, and nothing changes: the message says the decision is not theirs to make, the task keeps its status, and nobody downstream is notified. If that happens to you and the work is genuinely yours to sign off, ask the assignee to submit the verdict, or ask an admin to reassign the task to you first.

The same rule covers approval tasks and setup tasks, because all three are work only a person can do.

Score one

1. Open the task

   The Overview tab shows the subject preview above the rubric.

2. Score each row

   Every criterion takes a score, and the panel keeps a running weighted total against the passing score as you go.

3. Add notes

   Optional, and worth writing when the verdict is anything other than passed. A failing check needs the steps to reproduce it.

4. Choose the verdict

   Pass stays disabled until the total actually reaches the passing score, so a pass cannot be given by accident. Needs revision and Fail are always available.

Once submitted, the panel becomes read-only: the scores, the total, and the notes stay on the task as the record of the check.

What each verdict does next

A verification created as part of a larger piece of work reports back to its parent:

• passed moves the parent on. For a content task, that means your review.
• needs revision sends the parent back to drafting.
• failed kills the parent, with the failed verification as the reason.

A verification created on its own (a release gate, a nightly sweep) simply records its result.

A verification is a person's signature

Verification is the one thing an agent cannot do for you. An agent produces the work and the evidence; a person reads the rubric and signs it. That is why a verification task can only ever be assigned to a person, and why the verdict is recorded against a name.

Ship verification

Code delivery has a verification of its own, and passing it is the only thing that merges a branch. When a branch’s checks and its pull request review have both finished, CommandChain creates one and assigns it to the branch’s delivery owner.

Its rows are filled in from what actually happened on the branch, not typed in by you, so the rubric is read only. Pass is unavailable until every row is full, and a row sitting at zero names the thing to fix. The passing score is checked by the platform, not by the button, so a branch that is short of it cannot be passed from anywhere.

Each verdict acts on the branch:

• Pass merges it into the branch it was cut from, and every task on it moves to done.
• Needs revision opens a fix task.
• Fail closes the pull request.

A merge that conflicts is not a rejection: the pull request stays open, the Release tab says so, and you can resolve the conflict and ask for another review.

Who may submit the verdict is the rule above.

Creating one

+ New ▾, then Verification, on the Tasks page. A verification needs a rubric to score against, so most are created by the work that needs them (a content task entering verification, or an initiative’s acceptance criteria) rather than by hand.

All of them are filterable in one place: on the Tasks page, open Filters and set Type to Verification.

Next steps

• Run a content task: the pipeline that spawns verifications.
• Decide an approval: the gate after a pass.
• Task types: how the typed lifecycles fit together.