How a Playtest Live study runs

1. The brief

A study starts with the decision the team needs to make, not with a headcount. The brief captures the decision, the hypothesis, the game and its multiplayer format, the target date, and the cohort shape the question needs.

Submitting a brief reserves nothing and charges nothing. The reply says which of three things is true: it fits the lab’s current envelope, it needs a short scoping call, or it is not something this lab should deliver. The third answer is a real outcome, not a sales stage.

2. Protocol and cohort specification

The protocol is built from the study rather than written free-form: what participants will do, in what order, and what evidence each step is meant to produce. The cohort specification comes out of it: experience mix, roles, hardware tiers, region, route, language, accessibility requirements, exploration seats, and how many standbys.

Price and reward coverage are derived from that cohort, so the numbers cannot describe a session different from the one specified.

3. The session contract

The agreed study becomes a versioned contract: seats, roles, regions, hardware bands, times in a real IANA time zone, the reward model with its premiums, and the reward pool. Versions are immutable. A change creates a new version and leaves the old one on the record.

The reward pool is validated against every seat at its maximum premium before the contract issues, so a session cannot open with a roster it cannot pay for.

4. Allocation

Candidates are ranked in a fixed order: the session shape the contract requires, then verified regional and hardware coverage, then experience and reliability history. The reward amount is not read by the ranking at all. It is computed after a seat is filled, so it cannot influence who filled it.

Every assignment stores the reasons it was made, in the order the rules applied. Unfilled seats store why they could not be filled, which is usually the more useful record.

5. Awards and acceptance

An award is a written offer of one seat to one participant: the session time in their local zone, the total committed time, the fixed reward and any itemised premium, and the confidentiality and recording terms. It has an expiry.

Nothing about the reward can move downward afterwards. There is no code path that lowers it, and promoting a standby takes the higher of the two rewards. That is the mechanism behind the promise that reporting a problem never costs a participant money.

The studio sees counts and coverage. It does not see who declined, who was rejected, or any private note.

6. Readiness

Five checks, all required, per accepted seat: confidentiality accepted, build installed, build launched, connection checked, voice checked. Readiness is derived from the items, so nothing can be marked ready without the underlying checks existing, and there is no partial-credit state that reads as ready on a dashboard.

If an assigned rig changes, the readiness and premium that depended on it are invalidated rather than carried over. The operator works a follow-up queue against the seats that are not clear yet; the studio sees aggregate readiness and the risks, not individual chase notes.

7. The live session

Check-in, then the protocol. Everything that happens is appended to a timeline that cannot be rewritten: readiness events, replacements, technical and network problems, build issues, conduct matters, operator notes and neutral observations, each with a severity and a timestamp. A correction is a new entry, not an edit.

When a primary does not appear, a standby is promoted and the swap is recorded with its reason. That record is what makes “the session was short two attackers for the first twelve minutes” a known condition of the evidence rather than an argument afterwards.

The studio’s view of the timeline is a projection with participant identities and private detail removed.

8. Evidence and the decision pack

Findings are assembled from the timeline, the readiness record and the session funnel: awarded, accepted, ready at T–24, ready at T–2, attended, no-show, released, replaced. Each finding references the specific evidence behind it, and the assembly refuses a finding whose evidence cannot be traced.

Each finding also carries an explicit assessment: confidence, whether the evidence was consistent, mixed or contradicted, the scope it holds at (single session, tested cohort, tested build or tested region), and the recommended next test, which is allowed to be “replicate this before acting on it”.

Unpublished findings stay private. The published pack is what the studio receives, with the session conditions and any protocol deviations attached.

9. Rewards and reconciliation

Rewards are tracked in a segregated, increase-only ledger in integer minor units. There is no participant wallet or cash balance, no card or bank details are stored, and studio prepayment is never described as escrow because it is not.

Release of a reward is a manual operator action against a reconciled record. Payout automation is deliberately absent until it has been through legal, accounting and provider review.

What is deliberately not in this workflow

There is no automated matching, no public opportunity feed, no bidding on seats, no public ranking, no points, XP or reward store, no AI-authored findings, and no native recorder or launcher. Steam provides build access, Discord provides optional communication; neither is the system of record. Those absences are decisions, recorded with reasons, not gaps waiting to be filled.