How can an outside party verify when the prompt criteria were fixed?
Review platforms already version prompt criteria and retain rejected validation results. The open question is not whether the chronology exists, but whether anyone outside the workspace can check it.
The workflow
In generative AI document review the producing party writes prompt criteria, runs them against a validation sample, measures precision, recall and elusion against reviewer coding, adjusts the criteria if the numbers fall short, and repeats until the results are acceptable. The accepted criteria then run against the full population, and the producing party tells the requesting party how the process performed.
Validating before spending money on a full review is better than discovering the problem afterwards, and revising criteria that miss responsive material is what a careful producing party should do. The iteration is a feature, not a defect.
The platforms already keep the history, and that deserves saying clearly
One widely used platform versions prompt criteria automatically. Its documentation states that each analysis job that uses a unique set of prompt criteria counts as a new version, that the initial criteria are saved as Version 1 and edits create Version 2 and onwards, and that dashboard results from earlier versions remain viewable. Rejected validations are retained as well: even if you reject the results, Review Center keeps a record of them, and completed and rejected validation queues can be compared side by side.
Each aiR for Review project comes with automatic versioning controls so that you can compare results from running different versions of the prompt criteria. Each analysis job that uses a unique set of prompt criteria counts as a new version.
Relativity, aiR for Review documentation, “Developing prompt criteria”, read 10 September 2026
A producing party using such a platform is not working blind, and a reviewer inside the workspace can see the sequence.
So the question is not whether the chronology exists. It is where it lives.
The version history, the timestamps and the accept or reject decisions are maintained inside the platform environment used by the producing party. The vendor documentation we reviewed does not describe those timestamps as being independently time-evidenced outside that environment.
For an ordinary internal workflow that may be entirely sufficient. The question changes when an opposing party, a court-appointed expert or another external relying party has to verify the same chronology, because they are then asked to accept records produced within one side’s environment.
The practical form of the question is narrow. If you had to show that criteria version 4 existed before a particular validation result was known, what would you hand over, and what would let the recipient check it without relying on your instance?
We have not found vendor documentation describing an export of the criteria chronology that a third party can verify independently. The export documented for prompt criteria produces a Word file of the currently displayed criteria. That is a question worth putting to your own vendor rather than assuming either way.
A way to answer it that a third party can check
At the moment each criteria version is created, serialise it to a canonical form, hash it, and anchor the digest with time evidence you do not generate: an RFC 3161 timestamp from a public time-stamping authority and an entry in a public transparency log. Do it for every version rather than only the accepted one, because the sequence is the point.
Prompt criteria are work product, so publishing them is not an option. A sealed commitment fits the constraint: the digest and the time are public, the criteria stay private, and disclosure happens only if you choose it or a court orders it.
You can then establish that four specific criteria versions existed no later than four independently evidenced times, without disclosing their contents. If the validation record separately establishes when each validation run occurred, the two records can be used together to document the sequence.
What this does not prove
A record of this kind establishes that a specific criteria object existed no later than a particular time and has not changed since. It does not establish that the criteria were appropriate, that the validation ran after the anchor, or that the reported statistics are correct.
A validation record can supply the execution-side evidence, depending on its provenance. The ordering comes from reading the commitment evidence and the execution evidence together; the digest alone does not establish it.
The record format used in the examples above is PRML, an open specification with a registered media type. The procedure works with any format that produces a reproducible digest.
Do review platforms keep a history of prompt criteria versions?
Yes. At least one widely used platform versions prompt criteria automatically, keeps earlier versions viewable, and retains rejected validation results. The question this page asks is not whether that history exists but whether a party outside the workspace can verify it.
Why would an opposing party care when the prompt criteria were fixed?
Because the accepted criteria are usually accepted after earlier versions were measured and revised. A record that shows only the accepted criteria and their statistics does not let an outside reader distinguish criteria set in advance from criteria selected because they scored well.
Can this be done without disclosing the prompt criteria, which are work product?
Yes. A sealed commitment publishes only the digest and the time. The criteria themselves stay private and are revealed only if the holder chooses to or a court orders it.