---
interpretation: lens
---

**Mandate:** The agent **MUST** verify the prototype actually validated whether the core loop is fun, not whether it "runs" or "has features." The prototype's only output that matters is a defensible answer to one question: is the loop fun for the audience? Findings here block production — production resources committed against an unvalidated prototype are wasted resources.

## Check

The agent **MUST** verify, file feedback for any violation:

- **Playtests were run with non-team players.** The playtest record names at least three sessions with players outside the team. Sessions where only team members played do not count as fun validation — they validate that the team likes the prototype, which was never in question.
- **Player profiles match the concept's audience.** The audience unit from concept named a primary demographic and comparable titles. The playtest record must name at least two sessions whose player profile matches that audience. If the audience is "Souls fans" and every session was with casual mobile players, the validation does not transfer.
- **The fun verdict is supported by specific player observations.** The record must cite behavior ("session 03 player completed the loop 14 times in 12 minutes, then asked to keep playing") and verbatim quotes, not team opinion ("the team agreed it felt good"). The lens is whether **players** said it worked, on the evidence the record presents.
- **Per-pillar verdicts are named with evidence.** Every pillar from concept appears in the playtest record's per-pillar verdict table with Yes / No / Partial and a session reference. Silent pillars are forgotten pillars.
- **"It'll be fun once we add X" is treated as a NO verdict.** The prototype either validated fun or it didn't. Deferring fun to a future stage is the failure mode this lens exists to catch — production stage exists to scale a fun prototype, not to manufacture fun.
- **Negative feedback was engaged with, not dismissed.** If sessions surfaced concerns and the design-iteration record does not address them — by changing the design, by recording why the concern was rejected, or by surfacing the concern as a concept-level finding — that's a finding.

## Common failure modes to look for

- A playtest record with three sessions, all team members
- A "fun verdict: yes" with no instrumented data and no quoted player language to support it
- A pillar named in concept that is absent from the per-pillar verdict table (pillar was not tested)
- "Partial" verdicts that don't name what's missing or how the next iteration would close the gap
- A design-iteration record that ends without a final verdict — silence forwards an unresolved question into production
- Sessions where the playtester explained controls or mechanics before the player tried them (readability not actually tested)

When a finding is identified, file feedback against the prototype unit whose evidence is missing or insufficient, not against the stage in aggregate.
