A review can come back without overwriting your work.

Sender → reviewer → sender

1. In Test Bench, download a project backup. Expand Send evidence for review and import returned judgments, choose A, B or both, and download a review packet. Current nonblank latest recordings are included; missing, blank and prompt-stale pairs in that scope are omitted.
2. Inspect the packet before sharing through your chosen channel. It includes source, exact prompt/output/model/date, current checks/criteria and existing latest review context. It is not redacted or blinded.
3. The reviewer opens the packet in the local editor. Evidence is read-only there; they add a self-reported label, criterion ratings, explanations and explicit accept/reject decisions. They can download unfinished work too. Nothing is sent automatically or saved to browser storage.
4. Open the returned packet in the original Test Bench project. Preview each decision and the context it will archive. Undecided rows—including their partial ratings/notes—are skipped, not imported as reviews.
5. Confirm only when the returned judgments are appropriate. All completed rows apply together or none do. Existing reviews are archived; raw prompts/outputs/dates, drafts, earlier recordings and saved project decisions are not rewritten. Download a new project backup.

One reviewer label applies to the whole packet. It is editable text, not verified identity. Do not use it to imply that several people independently reviewed a file. The website has no account, email delivery, reviewer authentication, model execution or automatic semantic judge.

Worked return: old source-fidelity pass, stricter typed-value review

The source project contains 24 previously generated actual local-model outputs on four fictional support cases. Those outputs and their original execution worksheets were published earlier; no model was run for this review exchange. Original execution exercise and limits.

The packet exports only eight current latest records, not the sixteen earlier recordings. A separate browser context returns two same-agent judgments for the first case under the tightened criterion: monetary evidence must remain usable typed values, not only text. This is a workflow exercise with shared context, not an independent reviewer or blind evaluation.

• A: fail / fail / fail. The actual answer keeps GBP 12 as a string, uses broken and yes instead of the required enum/boolean, and wraps the answer in Markdown fences. The old source-fidelity pass remains archived.
• B: fail / pass / pass. It drops explicit amount/currency to null, but preserves the right issue/refund intent and returns the required raw JSON types. Rejecting overall does not erase the criteria that passed.
• A third unfinished note/rating is deliberately undecided and therefore not applied. The other six latest judgments and all earlier records stay unchanged.

Recipient labels are appended to imported notes as self-reported. The new review start date is the sender's device import time—not the recipient's completion time. Review changes can make existing project recommendations historical; their stored snapshots remain untouched.

• Original sender project — includes full prior history/drafts, not a reduced packet.
• Outbound eight-record review packet — open in the recipient editor.
• Returned packet with two decisions and one unfinished row
• Browser-exported project after confirmed import
• Read all retained evidence and archived judgments · Offline HTML handoff
• Artifact hashes, scope and sources

What the packet keeps—and what it does not

Version1 uses format promptkb-review-packet. It carries a project name, shared criteria, one reviewer label, an omitted-pair count and up to100 entries. Each entry includes case number/name/input, variant letter/name, current rules, original latest recording/current saved review, and an assessment of ratings/verdict/note. Only reviewer and assessment fields should be edited. Other metadata is an exact assignment guard, not an execution certificate.

Response/model drafts, earlier recordings, archived review contexts and saved project decisions are excluded. Existing latest review context is included for matching and may contain older criteria/private notes; this is not a blinded or redacted handoff. Current source and prompts can also contain private content. Files and sharing channels have their own risks.

UTF-8 JSON, up to10 MB. Existing Test Bench text/rule limits apply; up to8 criteria, reviewer label80 characters, each returned note1,800 characters so its unverified-label prefix fits the existing2,000-character project note field. Keep LF line endings in editable packet fields. Every criterion needs assessment before a decision; acceptance requires all pass, but all-pass never auto-accepts. Zero criteria still requires an explicit verdict. Raw JSON duplicate keys follow native parsing (last value wins).

This is a separate exchange envelope, not a new Test Bench project version. Stored imported judgments use existing review/archive fields. No reviewer completion timestamp, signature, multi-reviewer merge, automatic name-based remapping, earlier-record return target or server recovery is provided. Keep original project and return files separately. These scope choices are provisional, not guarantees about reviewer independence or model reliability.