How every session is checked
Four gates between capture and delivery.
A gameplay session is only useful if the input log actually describes the frame you are looking at. Each session we deliver passes four independent checks — two on the contributor's machine and in metadata, one on the decoded video, one by a trained reviewer. Each gate filters what the next one has to look at, so nothing reaches a human that a machine has already settled.
Capture integrity
Runs on the contributor's machine · blocks the upload
The cheapest place to catch a broken session is before it leaves the PC that made it. A session that fails here is never uploaded, and the contributor is told why.
Complete log set
All four input logs present, each with a valid start and end anchor. Without them there is no dataset — only a video.
Video / log agreement
Session length measured from the logs must match the recorded video within a bounded tolerance, so the input stream and the footage describe the same span of play.
Closed container
The recorder waits for the encoder to finalize the MP4 before packaging. A file moved early has no complete index and will not open downstream.
Real playtime
Sessions too brief to contain play are rejected. They produce a near-zero sync difference and would otherwise pass every other check while holding nothing.
Player present
No long continuous stretch without input, and no single idle stretch large enough to dominate the session. Filters recordings left running unattended.
Input actually captured
A minimum input density is required, scaled to the length of the session. This catches the hardest failure of all: clean footage with empty input logs.
Hashes at the source
SHA-256 of every log, the video and any engine demo file is written into the session metadata at capture time — certifying the originals, not a later copy.
Consent secured at the source
Recording is limited to titles on our reviewed whitelist, distributed to every recorder as a versioned list. Nothing outside it can be captured in the first place.
A session that fails any of these checks cannot be uploaded at all.
Server-side verification
Runs on metadata and logs · video not downloaded
We do not take the recorder's word for it. Every uploaded session is re-checked against the bytes that actually landed in storage, reading only a small fraction of the dataset's weight.
Hashes re-verified
Each file is re-hashed in place and compared to the value declared at capture. Any mismatch — corruption in transit or a post-hoc edit — rejects the session.
Every gate re-run
Sync, idle, input density, session length and container integrity are evaluated again with current thresholds, so an outdated recorder in the field cannot let anything through.
Coded outcomes
Each session lands in one of four states — approved, rejected, recoverable, or held for human review — each with a specific reason code rather than a generic failure.
Judgement calls held back
Ambiguous signals (inconsistent metadata, unusually low activity) are never auto-rejected. They are routed to a person by design.
session_id "s_04f19c…" state "held_for_review" gate_01 pass logs 4/4 · sync_delta_ms 41 · input_density 3.2/s gate_02 pass hashes 6/6 re-verified · thresholds v11 gate_03 flag dead_screen 0.31 → over threshold gate_04 pending reason_code "DEAD_SCREEN_REVIEW" measurements kept · reclassifiable without decoding again
Illustrative. Every delivered session carries a record in this shape, whatever the outcome.
Rejected sessions leave the pipeline here and never enter the human queue — nobody spends time on material already settled.
Video analysis
Runs on the decoded footage · prepares the review package
The first gate that looks at pixels. It settles what is objectively measurable and prepares what a person needs in order to judge the rest quickly.
Measurable format faults
Resolution, aspect ratio and frame rate are decided by the machine alone. There is nothing to interpret, so no reviewer time is spent on them.
Dead-screen detection
Keyframe luminance and variance flag long static or black stretches. Calibrated against known good and known bad sessions before any batch runs.
The review package
A contact sheet sampling the whole session at a fixed interval, short clips from across it, an audio waveform and a fact sheet — orders of magnitude lighter than the video itself.
Measurements kept, not just verdicts
Raw per-sample series are stored alongside the result, so a threshold can be revised and sessions reclassified without decoding the video again.
Illustrative proportions. Past the threshold, the session is flagged for a person rather than auto-rejected.
Reviewing every session becomes viable instead of sampling a fraction of them.
Human review
Trained reviewers · admin console · one verdict per session
The last gate decides what no machine asserts confidently today: whether this is gameplay, whether it is the title it claims to be, and whether anything on screen should not be shipped.
Is it gameplay
Sessions that are mostly desktop, menus, loading or cutscenes are rejected. A few minutes of menu inside an hour of play is normal and stays.
Is it the declared title
The reviewer confirms the footage matches the title recorded in the metadata.
Image faults
Broken, stretched, artefacted or fully black capture is rejected — distinct from footage that is simply low-definition.
Privacy and content
Personal data visible on screen, webcam faces, or explicit content outside the title's own rating are removed. Flagged on suspicion, not certainty.
Second opinion
Softer findings — third-party overlays, windowed capture, anything that looks staged — go to a second reviewer rather than a unilateral call.
Who wins a disagreement
The machine wins on objective faults. The reviewer wins over the dead-screen heuristic when they approve — they saw the frames, and the heuristic has produced false positives.
A recorded verdict per session, with the reviewer, the timestamp and the reason code attached.
What travels with the data
The verdict is part of the delivery.
Traceable
Every verdict carries the reviewer, the timestamp, the reason code, the threshold version it was judged under and a hash of the batch it belonged to.
Separated duties
Reviewers work read-only on review packages. They hold no write access to the database and no access to the source video.
Measured
A deliberate share of sessions is reviewed twice, which is how we measure agreement between reviewers and keep the rubric honest.
Portable
The verdict format is identical whatever tool produced it, so the record travels with the delivery instead of living inside one application.
