Skip to main content
A review session is one run of a configuration version over a chosen input. It is where generation, scoring, and human decisions all happen.

​
Starting a session

Creating a session binds three things:
1

A configuration version

Usually the published version. During development, the draft you want to test.
2

An input source

An index, another task’s stage output, or the exact outputs of one past session. Content sources
3

One option per variant dimension

The combination the session runs — for example Danish and B2C. Variants
Before re-running a configuration that has run before, look at its existing sessions. A comparison between two runs only means something if both cover the same documents.

​
Preview sessions and review sessions

Review activity separates the two, along with sessions you created yourself.

​
Review items

Each document produces one review item per variant combination. An item carries:
  • The generated output
  • One score per applicable quality rule, from 1 to 5
  • Written feedback from each rule
  • The gate’s verdict
  • Its current state — waiting for review, accepted, or declined
The session list shows one column per rule, so you can see at a glance which rule is doing the rejecting across the whole run.

​
The approval rate

The session header shows the share of items the gate passed. This is the number that matters: it is the honest measure of how much human attention the job will cost.
Quote the approval rate from a preview before committing to a volume. A configuration passing 90% of items is a completely different proposition from one passing 40%.

​
Decisions

For each item a person can: Accept quality gate approvals accepts every gate-passed item at once. That is the intended workflow at volume — let the gate handle the clear passes and spend attention on the rest.
Spot-check gate-approved items anyway, especially early on. In the first few sessions you are validating the gate as much as the content.

​
Reading rejections

The feedback tells you which rule failed and why. From that you can tell whether the generation is wrong or the rule is wrong — they need opposite fixes. Deterministic failures are precise: a schema failure names the path and the violated constraint, a forbidden-term failure names the matched text and pattern.
Be careful with grounding verdicts. An AI rule only sees the source document if it was given access. Without it, a rule can produce confident feedback about faithfulness to data it never received — read the rule’s configuration before acting on the verdict. Quality checks

​
Export

A session’s results can be exported from the session header, for sharing with people who do not work in Speedtrain.