The Vertical Slice: retire a risk and establish the Quality Baseline

A Vertical Slice must answer a production question with a playable cross-section of the intended game. It should expose a named risk while bringing engineering, art, audio, and player experience together at production quality.

At Clowdr, its approval has a specific consequence: the slice becomes the binding Quality Baseline and opens Production. This is a guide to that approved gate, not a claim that every project needs the same slice size or timetable.

Name the risk before counting content

Choose a risk that can change the production decision. In a hypothetical short exploration game, that might be whether players can read the route while the intended lighting and sound remain in place. Record what a useful answer would look like and what evidence could disprove the plan.

Tie the question to the approved Player Promise. A slice can be technically competent and still fail to support the experience for which the Project was approved.

Cap the cross-section and give it a review date

Define the smallest integrated section that can answer the question at the intended quality. List the included player path, the required craft work, the platform, and what remains outside this milestone.

Set a review date with people who can play or inspect the build. A date creates a decision point; it does not waive quality requirements. If the evidence will be incomplete, explain the gap before the review.

During the Slice Phase, only tasks needed to build, integrate, and evaluate this slice are claimable. The wider roadmap can be visible, but it waits for Quality Baseline approval.

Review the playable build and its limits

Bring a versioned build and the conditions under which it was checked. Demonstrate the intended player path. Include relevant playtest observations, the integrated craft decisions, remaining defects, and source or rights questions.

Separate an observed finding from a planned fix. “Players missed this signal in this test” describes evidence. “The next pass will solve readability” describes an intention. Neither should be reported as a broader success rate without the data.

Clowdr evaluates the slice against the Player Promise and approves it as the Quality Baseline before broader Production begins. A contributor's completed task or a Lead's confidence cannot substitute for that approval.

Keep the baseline usable after approval

Preserve the reviewed build version and a short record of its defining quality decisions. Later work can improve or deliberately evolve the direction, but the complete game cannot quietly fall below the coherence and polish that earned Production.

Publication Review compares the complete game with this baseline, the approved Feature Scope, and the Five Proofs of Release. Revision requests must be explainable against those references.

Use How We Ship for the lifecycle and scope control to distinguish repairs from new capabilities. The slice should leave the project with evidence, a quality reference, and a clear next gate.