11. Review, Playtest, and Release

The campaign is feature-complete, but feature-complete is not the same as release-ready. This final chapter turns the working campaign into a named release candidate, reviews it independently, records human playtest evidence, and gives the human campaign owner enough information to make a responsible release decision.

Start from the restored Checkpoint 9 campaign, not the intentionally broken Checkpoint 10 variant. You can also download the Chapter 11 review package worksheet.

What you will build

You will finish with two deliverables:

1. a stable tutorial_codex.json release candidate, and
2. a review package containing the dependency ledger, validator result, independent review, human playtest notes, finding dispositions, residual risks, and owner decision.

The campaign JSON is the product being evaluated. The review package is the evidence explaining why it should—or should not—be released.

What you will learn

• Why validation, review, playtesting, and release approval are separate gates
• How to freeze a release candidate so every result refers to the same payload
• How to label evidence without overstating what it proves
• How a Campaign Reviewer assigns severity and issues a bounded verdict
• How to turn a progression graph into an adversarial playtest matrix
• How to record a finding, correction, and required re-test
• Why the human campaign owner remains the final release authority

Starting state

Before reviewing anything, undo the Chapter 10 teaching defect.

Your working campaign must again contain:

recover_letter.completeWhen.hasItem
no tutorial_codex:fragile_letter_event trigger
Oren checks hasItem rather than objectiveCompleted

Validate the restored campaign and confirm:

0 errors
0 warnings

That result establishes that the payload is acceptable to the validator. It does not prove that every quest path is reachable, that the player understands the directions, that the encounter is balanced, or that the ending returns control correctly.

Do not review a moving target

Once review begins, stop casually editing the candidate. A validator result, review finding, or playtest note is useful only when it identifies the exact payload that produced it.

Step 1 — Freeze the release candidate

Save the restored file as:

tutorial_codex.json

Record a small identity block in your review package:

## Candidate identity

- Campaign ID: `tutorial_codex`
- Title: The Drowned Bell
- Campaign version: `1`
- Candidate label: `tutorial_codex-v1-rc1`
- Candidate date: YYYY-MM-DD
- Payload filename: `tutorial_codex.json`
- Based on tutorial checkpoint: 9

The candidate label is review metadata; it does not replace the campaign’s stable id or arbitrarily increase its public version.

If you change the payload after a finding, create a new candidate label such as:

tutorial_codex-v1-rc2

That lets you say exactly which candidate failed, what changed, and which candidate passed the re-test.

Preserve the approved design baseline

The Reviewer needs to know what the campaign was supposed to become. For this tutorial, the approved decisions include:

• Greyhaven as the town
• Mara Vey, Brother Oren, and Lysa Fen as the cast
• two linked quests
• letter-first exploration as a supported path
• Lysa as a Seer
• a two-level Drowned Belfry
• the Echo Warden as the custom boss
• return to Oren before the ending
• continued free-roam play after victory

A technically valid payload that removes the letter-first route or ends immediately after the boss would still fail design fidelity.

Step 2 — Assemble the evidence packet

Give the Campaign Reviewer the best available version of each artifact:

Artifact	Purpose
Approved design baseline	Defines intended player experience and approved decisions
Release-candidate JSON	Shows the implementation actually under review
Implementation notes	Records important choices, assumptions, and approved deviations
Dependency ledger	Makes producers and consumers visible
Validator result	Establishes contract and reference findings covered by the validator
Playtest plan	States what must be exercised by a human
Prior findings	Prevents fixed defects from disappearing from history
Playtest evidence	Supports—or blocks—a release-decision verdict

Missing evidence is itself a review limitation. The Reviewer should say that the artifact was not supplied rather than guessing what it contained.

Use evidence labels precisely

Use the following labels in the package:

Evidence label	What it supports
Confirmed by contract	A field, action, condition, event, or registry value is supported
Confirmed by validator	Named validator output passed or rejected a rule
Confirmed by runtime/test	A regression or observed runtime path demonstrated behavior
Static inference	Structure and dependencies imply a result, but the path was not executed
Playtest required	Human interaction is needed to establish the claim
Creative decision required	Several valid choices remain and the owner must choose

Consider the claim:

Finding the letter before speaking with Mara does not block the campaign.

That one claim needs several layers:

contract
→ hasItem is a supported condition

validator
→ the quest, item, objective, and dialogue references are valid

runtime/test
→ starting the quest while carrying the letter completes the objective

human playtest
→ the player understands what to do next and reaches Oren

Do not collapse those into the vague statement “verified.”

Step 3 — Rebuild the dependency ledger independently

The Technical Implementer may provide a dependency ledger, but the Campaign Reviewer should trace the critical graph independently and compare the two.

For The Drowned Bell, the minimum ledger is:

Consumer	Depends on	Producer
Mara quest dialogue	Quest 1 status and letter inventory	Mara’s start actions and the courier satchel
recover_letter	tutorial_codex:sealed_letter in inventory	Courier satchel chest
Oren letter resolution	Quest 1 active and sealed letter owned	Mara dialogue and courier satchel
Quest 2 start	Quest 1 completion	Oren’s letter-resolution branch
Recruit-Lysa objective	tutorial_codex:lysa_recruited	Targeted companionRecruited trigger
Enter-Belfry objective	tutorial_codex:belfry_entered	Targeted enterDungeon trigger
Defeat-Warden objective	tutorial_codex:warden_defeated	Targeted combatVictory trigger
Final Oren resolution	Quest 2 active and Warden defeated	Echo Warden victory trigger
Campaign ending	tutorial_codex:campaign_complete	Final Oren dialogue

For each row, ask:

1. Is the producer reachable?
2. Can it happen before the consumer is ready?
3. Can it happen only once?
4. Is the result durable across save and reload?
5. Can a broader dialogue branch hide the intended branch?
6. Can an unrelated target accidentally satisfy it?
7. Does the ending depend on the intended final action?

Chapter 10 demonstrated why this graph matters. The fragile item-acquisition trigger looked reasonable in isolation. The producer became unreachable only when timing, one-time acquisition, and the later objective consumer were analyzed together.

Step 4 — Run validation and preserve the result

Open the release candidate in the public Author tools and run validation.

Record:

## Validator evidence

- Candidate: `tutorial_codex-v1-rc1`
- Result: Pass
- Errors: 0
- Warnings: 0
- Evidence label: Confirmed by validator
- Notes: Validator success does not establish path reachability, persistence,
  balance, presentation clarity, or input-state recovery after the ending.

A screenshot may be useful, but a screenshot alone is weak evidence if it does not identify the candidate. Pair it with the filename and candidate label.

What the validator contributes

A clean result supports claims such as:

• required campaign shape is present,
• known campaign-owned references resolve,
• supported action and condition shapes are used,
• known trigger events and target references are acceptable,
• the ending uses a valid condition and action structure.

What the validator cannot decide

It cannot reliably prove:

• Mara’s directions are clear,
• the letter-first route feels natural,
• the Echo Warden is beatable by the intended party,
• the milestone button accurately describes its behavior,
• dialogue closes before the ending takes input focus,
• save/reload preserves every important transition,
• the campaign is enjoyable,
• remaining risks are acceptable.

The validator is evidence, not authority to release

A clean validator result can move a candidate into deeper review. It cannot promote the candidate to release on its own.

Step 5 — Request an independent Campaign Reviewer pass

The Campaign Reviewer should receive the evidence packet in a fresh review context when practical. The Reviewer does not silently rewrite the campaign and does not inherit the Implementer’s confidence as proof.

Ask for one of these verdicts:

• Blocked
• Needs implementation fixes
• Ready for human playtest
• Ready for release decision

The last verdict is deliberately phrased as ready for a decision, not “approved for release.” Approval belongs to the human campaign owner.

Apply severity consistently

Severity	Use it when
Blocker	The review cannot proceed meaningfully, such as a missing approved baseline or unusable payload
Critical	The main quest or ending is unreachable, persistent state is materially corrupted, or a core progression event cannot occur
Major	A meaningful path, placement, trigger, reference, or design requirement is wrong
Minor	A limited edge case or confusing presentation issue should be corrected but does not block the main path
Note	An observation, optional improvement, accepted risk, or suggested playtest

Severity describes impact, not how impressive the report looks.

Write actionable findings

Every finding should identify:

• a stable finding ID,
• severity,
• area,
• evidence label,
• affected path or ID,
• expected behavior,
• observed or inferred behavior,
• player or maintenance impact,
• smallest recommended correction,
• required re-test.

For example:

### REV-003 — Letter-first route loses its only completion event

- **Severity:** Major
- **Evidence:** Static inference; playtest required
- **Affected path/ID:** `tutorial_codex:missing_courier/recover_letter`
- **Expected:** Opening the satchel before accepting Quest 1 must remain completable.
- **Observed or inferred:** The one-time `itemAcquired` event is gated by
  `questActive`, so opening the satchel early consumes the event before its
  completion action is eligible.
- **Impact:** A supported player order soft-locks the main quest.
- **Recommended correction:** Restore the current-state `hasItem` objective
  condition and remove the fragile acquisition trigger.
- **Required re-test:** Letter first, Mara second; include save/reload before
  speaking with Mara.

That finding is useful because it names the dependency failure and the exact re-test. “The quest might break” is not useful.

Learn from the real review history

The canonical tutorial campaign encountered two release-blocking documentation and packaging findings before human playtesting:

1. The approved design baseline was not recorded clearly enough.
2. Several artifacts disagreed about the canonical payload filename.

Neither required redesigning the story. The smallest correction was to record the approval evidence and align every reference to the same filename.

This is good review behavior: fix the narrow defect, preserve stable IDs and approved intent, then re-run the affected checks.

A candidate with clean validation and no unresolved Blocker, Critical, or release-relevant Major finding may receive:

Ready for human playtest

That verdict means the remaining uncertainty must be exercised in the game.

Step 6 — Execute the human playtest matrix

Use a fresh game whenever a scenario depends on initial ordering. Do not reuse one save for every row and assume the results are independent.

Record the candidate, starting state, steps, expected result, observed result, and pass/fail outcome.

Scenario	Expected result	Evidence to record
Talk to Mara, then find the letter	Quest progresses normally	Objective state and next direction
Find the letter, then talk to Mara	Existing item is recognized; campaign remains completable	Inventory, objective update, Oren path
Talk repeatedly to Mara	No duplicate quest start or reward	Quest log and inventory before/after
Talk to Oren without the letter	No premature transition to Quest 2	Dialogue and quest state
Recruit Lysa	Recruitment objective completes	Companion state, flag, objective
Dismiss and re-recruit Lysa	Completed progression remains intact	Objective state before/after dismissal
Enter another dungeon, if available	Belfry objective does not complete	Objective remains incomplete
Enter the Drowned Belfry	Entry objective completes once	Message, flag, and objective
Defeat a non-boss monster	Warden trigger does not fire	No Warden flag or milestone
Defeat the Echo Warden	Flag, objective, and milestone fire once	Message box and quest state
Save after the boss, reload, return to Oren	Final resolution remains available	Reloaded flags and Oren branch
Complete the campaign and close the ending	Exploration controls resume	Movement and input after closing
Complete the campaign and reload	Ending state remains one-shot and persistent	No duplicate ending side effects
Repeat final dialogue	No duplicate quest completion or ending effects	Stable quest and ending state
Fight the boss with the intended early-game party	Encounter is achievable without hidden requirements	Party, resources, outcome, difficulty notes

Test the seams, not only the happy path

The highest-value scenarios cross boundaries:

exploration → quest start
inventory → objective state
dialogue → quest transition
companion state → durable flag
dungeon event → quest objective
combat victory → milestone
save/reload → final dialogue
dialogue close → ending message → exploration controls

Bugs often live between systems rather than inside one JSON object.

Record observations, not conclusions

Prefer:

After closing Continue Exploring, the map remained visible but arrow keys and
WASD produced no movement. Opening the menu also failed.

over:

The ending is broken.

The first note can be reproduced and diagnosed. The second is only a conclusion.

Step 7 — Triage playtest findings without hiding them

The canonical campaign’s human playtest exposed several useful findings:

Finding	Disposition
Opening did not direct the player clearly enough to Mara	Added explicit tavern guidance without auto-starting Quest 1
Brother Oren’s sprite was too small for an important NPC	Replaced it with appropriately scaled authored art
Boss milestone button implied a return or teleport that did not happen	Renamed the button to Continue
Ending did not state victory and continued exploration clearly enough	Expanded the copy and added Continue Exploring
Dialogue-triggered ending restored a stale dialogue input state	Escalated as a runtime defect, fixed the shared runtime path, and added regression coverage

The last finding is especially important. The correct response was not to invent a strange campaign-data workaround. The campaign exposed a shared runtime timing bug: the ending was evaluated before dialogue fully closed, so the ending box captured the wrong prior engine state.

When the defect belongs to the runtime:

1. preserve the campaign finding,
2. identify the smallest reproducible path,
3. escalate it to the runtime maintainer,
4. fix the shared behavior,
5. add a regression,
6. re-test the campaign path.

A Reviewer should not disguise an engine defect as author error.

Keep a finding disposition table

Use one row per finding:

Finding ID	Severity	Disposition	Candidate fixed in	Re-test	Status
PT-001	Minor	Corrected opening guidance	rc2	Fresh-game intro	Pass
PT-002	Minor	Replaced Oren sprite	rc2	Visual inspection	Pass
PT-003	Minor	Renamed milestone button	rc2	Boss victory	Pass
PT-004	Major	Fixed dialogue-ending runtime timing	rc2 plus runtime fix	Final dialogue through resumed movement	Pass

Do not delete a finding after fixing it. The history explains why the change exists and what future regression must protect.

Step 8 — Revalidate and re-test the corrected candidate

Any payload change invalidates the prior validator result for the modified candidate. Any runtime change invalidates the prior runtime observation for the affected path.

For each correction:

1. create the next candidate label,
2. describe the smallest change,
3. run validation again,
4. re-run the finding’s required scenario,
5. run nearby regression scenarios,
6. update the disposition table,
7. preserve failed and passing evidence.

For the dialogue-ending fix, the nearby regression scenarios include:

• final Oren dialogue closes,
• ending opens after dialogue,
• closing Continue Exploring restores movement,
• reloading does not replay one-shot effects,
• unrelated dialogue still returns to exploration normally.

A focused re-test proves the correction. A small surrounding regression set checks that the correction did not damage adjacent behavior.

Step 9 — List residual risks honestly

A release package should still list what is not fully established.

For a small campaign, residual risks may include:

• balance was tested with only a limited set of party builds,
• optional unrelated dungeon-entry targeting had limited coverage,
• visual presentation may vary with future generic appearance changes,
• browser or device combinations outside the tested set were not exercised,
• subjective pacing and difficulty may need adjustment after broader player feedback.

Residual risk is not an admission of failure. It is a boundary around the evidence.

Do not write:

No known risks.

unless the review genuinely supports that claim. More often, write the exact scope tested and what remains uncertain.

Step 10 — Issue the re-review verdict

The Campaign Reviewer can issue Ready for release decision only when:

• required human playtests are documented as passing,
• material findings were corrected, re-tested, or explicitly accepted,
• save/reload evidence exists for persistent state,
• ending reachability was demonstrated,
• residual risks are listed.

A concise final verdict might read:

**Verdict:** Ready for release decision

The candidate validates with zero errors and zero warnings. The normal and
letter-first Quest 1 routes, companion progression, targeted dungeon and boss
events, save/reload after the boss, final Oren resolution, one-shot ending, and
post-ending control recovery were playtested successfully. All material review
and playtest findings have been corrected and re-tested. Residual risk remains
around broader party-balance coverage and untested browser/device combinations.

The Reviewer is saying that the evidence is complete enough for the owner to decide. The Reviewer is not publishing the campaign and is not accepting the risks on the owner’s behalf.

Step 11 — Record the human release decision

The human campaign owner chooses one disposition:

Decision	Meaning
Release	The evidence is sufficient and the listed risks are accepted
Hold	More correction or evidence is required
Limited release	A smaller audience or narrower rollout is appropriate while specific risks are observed
Reject candidate	The candidate does not preserve the intended experience or requires material redesign

Record the decision:

## Human owner decision

- Candidate: `tutorial_codex-v1-rc2`
- Reviewer verdict: Ready for release decision
- Decision: Release / Hold / Limited release / Reject candidate
- Accepted risks:
  - ...
- Required follow-up:
  - ...
- Approved by:
- Decision date:

Human approval is not a ceremonial checkbox

The owner may hold a candidate even after a ready-for-decision verdict. The owner may also accept a documented non-critical risk. Those are product and creative decisions, not validator outcomes.

After approval, preserve the exact approved JSON and its review package together. Do not upload a differently edited file under the same evidence record.

Complete Chapter 11 package

Your final folder can be as simple as:

the-drowned-bell-release/
├── tutorial_codex.json
├── approved-design-notes.md
├── dependency-ledger.md
├── validator-result.md
├── campaign-review.md
├── human-playtest-notes.md
├── findings-and-dispositions.md
├── residual-risks.md
└── release-decision.md

For a compact project, the Markdown material may live in one review-package file. Separation matters less than clarity, candidate identity, and traceable evidence.

The downloadable worksheet combines those sections into one document.

Final verification checklist

Before presenting the candidate to the owner, confirm:

• The reviewed file is the restored working campaign, not Checkpoint 10.
• Campaign ID, version, filename, candidate label, and date are recorded.
• Approved creative decisions are identified.
• Validator result names the candidate and records errors and warnings.
• The Reviewer independently traced the critical dependency graph.
• No unresolved Blocker, Critical, or release-relevant Major finding remains.
• Normal and letter-first routes were tested from fresh games.
• Repeated interaction and wrong-target scenarios were tested.
• Save/reload was tested around important persistent transitions.
• The ending was reached through the intended return-to-Oren path.
• Controls resumed after the ending closed.
• Every material correction has a required re-test and recorded result.
• Residual risks are specific and visible.
• The human campaign owner recorded the final decision.

You have completed the tutorial

You began with an empty campaign shell and finished with:

• a namespaced campaign,
• Greyhaven and its services,
• story NPCs and ordered dialogue,
• two linked quests,
• out-of-order-safe item progression,
• a recruitable companion,
• a two-level dungeon,
• a custom boss,
• targeted once-only triggers,
• a milestone and campaign ending,
• one validator-error exercise,
• one validator-clean soft-lock exercise,
• an independent review package,
• human playtest evidence,
• and an explicit release decision.

The most important result is not the amount of JSON. It is the evidence discipline around it:

creative intent
→ supported implementation
→ validation
→ independent review
→ adversarial human playtesting
→ corrected and re-tested findings
→ human release decision

That is the complete campaign-authoring loop.

What to build next

Use the same process for your own campaign, but keep the first release smaller than your full ambition. Begin with one town, one clear quest chain, one meaningful alternate order, and one ending. Prove the workflow on a compact campaign before scaling the content graph.