voss review is read-only — it reads persisted .review.json sidecars and constructs no live providers.
Reviewer-A — authors the bar
Reviewer-A derives the verification bar from the original human idea — not the EM’s acceptance criteria, tickets, or any prior review. It runs with a fresh memory per card so there is no cross-card bleed.- For code cards it authors a test, runs it via
shell_run, and the exit code is the verdict. - For AI cards it authors a PASS/FAIL rubric, then judges against it.
Reviewer-B — judges narrative-blind
Reviewer-B judges the artifact, diff, and Reviewer-A’s verification summary using only the card’s own attributes — original idea, acceptance criteria, artifact, diff, and A’s summary. It sees no EM plan, tickets, or A’s reasoning process, so it cannot be talked into a pass by the orchestrator’s narrative. It runs at two tiers:fast at intermediate gates, strong at the gate to Done. If Reviewer-A’s verification has diverged from what the original idea requires, Reviewer-B can return block to abort the lineage.
The verdict
Both reviewers emit a frozenReviewerVerdict:
Persisted artifacts
Each card writes a<node_id>.review.json sidecar (mode 0o600) next to its session-tree node, under .voss/sessions/<root_id>/:
voss review.
Requirement assessments
Projects that opt into Jev judgments can add an advisory check beside Reviewer-B. Jev reads the diff, the changed code, and check results, and answers once per acceptance criterion: supported, contradicted, unclear (abstained), or no answer. A label needs a probability of 0.80 or more; anything below that is unclear. The results never approve, block, retry, or move a card, and never change Reviewer-B’s verdict. Today they run automatically for swarm candidates when.voss/config.yml sets judgments.review: shadow, and on demand:
voss audit shows saved results under “Requirement assessments (advisory)”. On the second locked evaluation set, Jev called an unmet requirement met once in 33 and left about a third of requirements unclear.