Task-Evidence Matrix
Evidence should answer the claim being made. More evidence is not automatically better; unrelated evidence creates noise and false confidence.
For each material claim, name the production consumer, intended environment, and dependencies that can change the outcome. Select the smallest consumer-complete verification route that includes them. This does not mean maximizing test scope. A unit test can completely answer a pure-rule claim; claims about input, composition, middleware, frame continuity, platform behavior, or player experience require those consumers. Lower-level evidence remains valuable support and diagnosis, but does not prove omitted boundaries.
Every material result has coordinates:
| Dimension | Examples | Question answered |
|---|---|---|
| Class | Static, deterministic, composed runtime, visual, experiential | What kind of claim can this support? |
| Provenance | Local, CI, hosted, maintainer, reviewer/player | Who or what produced it? |
| Scope | Editor, native, web, multiplayer, middleware, platform | Where does it apply? |
| Outcome | Passed, failed, inconclusive, unavailable, not attempted | What happened? |
| Revision | Immutable source commit | Which code/content was exercised? |
| Effective toolchain | Actual editor/compiler/middleware version | What actually ran? |
The current invocation must produce the operation's declared completion signal. A zero exit without that signal is inconclusive, and an older result file at the expected path is not evidence that the current invocation ran. Use a fresh result path or verify invocation identity and freshness before reading it.
When independent commands can occur in the same frame, transaction, request, or lifecycle callback, define their precedence or explicitly mark the combination unspecified. A claim-complete evaluator must exercise combinations that can materially change state. Passing each command in isolation does not prove their composition, and a green suite does not make divergent untested semantics equivalent.
| Task | Primary evidence | Additional human judgment | Common false proof |
|---|---|---|---|
| Pure gameplay rule | Unit, property, or deterministic rules test | Balance may still need playtest | Compilation |
| Runtime system | Focused tests plus composed runtime smoke | Behavior readability | Isolated mock only |
| Composition or lifecycle | Full startup, reset, transition, and teardown smoke | Transition feel | Constructor compiles |
| UI layout | Live production UI at relevant viewports, scale factors, content states, and layer composition; capture only for a named remote or comparison consumer | Hierarchy and polish | UXML or prefab imports, or screenshots from a substitute composition |
| UI interaction | Scripted mouse, keyboard, and controller paths through the real input adapter, focus owner, modal gate, and production view; composed inspection of the intended player affordance | Discoverability, responsiveness, focus feel, and accessibility | One input path, direct callback, or visible but unwired control works |
| Object, material, or texture integration | Native asset, prefab, scene, or game view containing the relevant production renderer at the angles and gameplay distances needed by the claim, plus artifact/material integrity checks | Silhouette, fit, style, and finish | Front view, successful import, or a detached substitute renderer |
| Animation | Observed continuous playback through the production animation path at the relevant camera and distance; exact normalized-time samples only when they answer a diagnostic or comparison question | Weight, rhythm, appeal, and transition feel | Animator state exists, isolated stills, or timed state cuts encoded as video |
| Closed gameplay loop | Deterministic input rehearsal through the composed scene and authoritative state, plus inspection that the ordinary production surface presents the required actions and mode | Human play judges comprehension, usability, engagement, desire to continue, pacing, and fun | Virtual input reaches the final state through hidden knowledge |
| Visual effect | Deterministically reset live playback through the production renderer and gameplay context, plus renderer/material integrity checks; fixed time samples only when diagnosis or comparison needs them | Taste, timing, legibility, and impact | Particle system exists or one flattering frame |
| Scene or environment | Live production camera anchors and routes at representative quality, lighting, and gameplay states | Composition, navigation cues, atmosphere, and gameplay readability | Scene opens without errors or an isolated beauty shot looks good |
| Procedural generation | Invariant tests plus live production review of permanent representative/failure seeds and bounded exploratory seeds | Route readability, variety, rare composition quality | Small synthetic fixture, aggregate counts, or discarded bad seeds |
| Physics or traversal | Preserved reproduction, diagnostics, Play Mode | Movement feel | Mathematical plausibility |
| Performance | Profiler capture, frame timings, allocation evidence | Acceptable experience on target hardware | Async method signature |
| Loading | Stage timings and observed frame gaps through the production loading overlay under real work | Overlay continuity | Work was split into tasks |
| Standalone player build | Project-owned build receipt, clean revision, exact scene list, settled build log, and complete artifact-tree hash | Whether the player launches, performs, distributes, and is acceptable to release | BuildPipeline returned success |
| Standalone player launch | Exact built artifact, project-owned readiness receipt, nonce, bounded process result, settled player log, and unchanged artifact-tree hash | Real input, visual correctness, representative performance, distribution, and release acceptance | The app process exited zero |
| Audio or middleware | Authoring event, generated output/media, runtime backend/emitter event, handoff, and state | Mix and emotional effect | Audio file or authoring preview works |
| Asset or prefab integration | Serialized reference audit plus the production resolver/factory in a composed scene | Scale, grounding, material fit | Asset exists in project or isolated preview |
| Content tuning | Authored value trace and playtest | Balance | Value changed in inspector |
| Architecture refactor | Characterization tests, dependency check, composed startup | Navigability | Smaller files |
| Documentation | Code and tool cross-check, link validation | Comprehensibility | Text is internally consistent |
| Release or checkpoint | Clean status, intended diff, required build or smoke | Release decision | Commit exists |
Gameplay Design And Experience Claims
Automated gameplay evidence is strongest where the claim can be defined in state, time, geometry, input, or an encoded policy. It becomes advisory when the claim concerns likely human interpretation, and it cannot grant experiential or product acceptance.
| Evidence class | Agent contribution | Claim boundary |
|---|---|---|
| Direct mechanical | Rules, transitions, invariants, reachability, softlocks, curves, distributions, latency, and explored strategies | Valid for the declared model, seed range, policy, hardware, and production consumer |
| Advisory proxy | Likely clarity, difficulty, pacing, readability, balance, novelty, repetition, or accessibility risk | Hypothesis for design discussion or playtest; not a player finding |
| Human designer judgment | Target player, fantasy, intended feeling, identity, priorities, tradeoffs, and acceptable compromise | Project direction, not audience evidence |
| Direct human play | First-time comprehension, control feel, perceived fairness, engagement, frustration, delight, comfort, and desire to continue | Valid for the people, build, context, and method observed |
| Representative player research | Findings from players matching a named target population | Supports that population only; sampling and study limits remain |
Telemetry says what happened. Observation and self-report help establish how it was experienced and why. A synthetic player demonstrates the policy and utility function it encodes, not a human response. See Human-Led Gameplay Design and Systems-Heavy Gameplay Evidence.
For a systems-heavy loop, keep these narrower claims separate:
| Claim | Direct or supporting evidence | Human evidence still required | Common false proof |
|---|---|---|---|
| Alternatives exist | Production state inspection, rule tests, reachable-action enumeration | Whether the intended player perceives the alternatives | Options exist in source |
| Alternatives remain viable | Sensitivity analysis, policy search, telemetry, and counterexample seeds under declared assumptions | Whether players understand and value the tradeoff | Equal pick or win rates |
| Consequence is presented | Event-to-feedback trace, latency, channel agreement, persistence, and blocked-reason checks | Causal clarity, impact, comfort, and emotional fit | A sound, particle, or number appears |
| UI supports a decision | Production comparison state, deltas, focus, input parity, overflow, and recovery checks | Readability in motion, discoverability, cognitive load, and confidence | All variables are visible |
| Onboarding teaches the core | First-use state path, trigger coverage, replayable help, and recovery checks | Uncoached first-session comprehension and transfer | Tutorial text was shown |
| Loop supports the declared motivation | Available control, challenge curves, recovery, progress signals, social routes, and expression opportunities | Felt volition, competence, connection, curiosity, ownership, or restoration | Rewards, activity, retention, or automated completion |
| Pacing matches the design | Response, decision, encounter, session, and long-term timing traces | Tension, fatigue, boredom, relief, and desire to continue | Faster completion |
| Progression changes play | Unlock graph, option-space delta, build diversity, and power-curve analysis | Whether new possibilities feel motivating or meaningful | Numbers or bars increase |
| Balance serves a goal | Declared balance objective, outcome distributions, counterexamples, and policy analysis | Fairness, identity, perceived power, adaptation, and enjoyment | Every choice has the same rate |
| Accessibility barriers are addressed | Configuration, remapping, focus, contrast, motion, timing, sensory redundancy, and procedural-barrier checks | Comfort and usability for the people represented by the claim | An accessibility menu exists |
| Players enjoy the loop | Mechanical evidence can stabilize the build and generate hypotheses | Direct human play; representative players for audience claims | Retention, session time, a theory checklist, or a fun score |
Visual Evidence Selection
Use engine-native Visual Work when a visual claim depends on angle, state, time, resolution, distance, or procedural seed. The surface must contain the production consumer and context material to the claim. Use an existing engine preview or direct game route for one-off review. A codex, gallery, bestiary, model viewer, world previewer, or inspect mode belongs in the ordinary project backlog when a named player, author, or recurring developer job independently earns it; it is not STAGE evidence infrastructure. Export durable evidence only when the claim needs persistence, comparison, CI, or review outside the engine.
The coordinates below describe state that may need to be reproduced; they do not require a capture set. For a co-located one-off review, use only the coordinates material to the question and leave the live native surface ready for the human. Exact camera matrices, retained samples, and immutable baselines belong to stable comparison or external-review workflows with decision-bearing artifact consumers.
A project map can make native subjects, recurring questions, human and agent entry points, actual native state and playback semantics, presentation authority, lifecycle, operations, and limitations discoverable. It does not prove that an operation ran, the stated frame was rendered, or the subject looks correct. Record native execution, observed output, and human judgment separately.
| Claim | Coordinates when repeatability is material | Keep separate |
|---|---|---|
| Subject is visually intact | Stable subject locator, relevant native views and distances, lighting/quality state, and resolution when material | Human style approval |
| Animation does not visibly snap | Exact clip/state, reset policy, continuous production playback, and diagnostic samples only where needed | Perceived motion quality and input responsiveness |
| VFX has no missing or fallback rendering | Exact production sequence, deterministic seed/reset when supported, continuous playback, and renderer/material integrity | Impact and timing in live combat |
| UI remains legible | Named state, viewport, scale factor, input focus, composed layer policy | Accessibility and navigation feel |
| Environment remains readable | Named production anchors/routes and quality/lighting state; exact camera coordinates only for comparison | Exploration and combat feel |
| Procedural visuals retain quality | Permanent representative/failure seeds, bounded exploratory seeds, and comparable production views when needed | Exhaustive seed coverage |
| Candidate matches approved intent | Immutable human-approved baseline and semantic-key comparison | Acceptance of any observed change |
Objective checks answer whether evidence is intact and grossly plausible. AI review answers what appears noteworthy under declared rubrics. Human review answers whether the result satisfies product intent. Do not collapse these three decisions into one status.
An offscreen composite can prove that named world and UI layers render together at an agreed viewport when each layer is asserted independently. It does not, by itself, prove the exact interactive backbuffer, input behavior, legibility in motion, visual quality, or player understanding.
A virtual-device rehearsal can prove that input mappings and composed runtime owners reach an intended mechanical outcome. It does not prove that the ordinary production surface presents the action. Inspect the intended control, prompt, tutorial, convention, or diegetic cue separately and verify that it uses the same production path. Neither result, by itself, proves a physical device, operating-system handoff, input feel, accessibility, player understanding, or enjoyment. Preserve mechanical, presentation, and human acceptance results as separate evidence entries.
A standalone player-build receipt can prove which clean revision, Unity toolchain, scenes, and artifact bytes were assembled. It does not prove that the artifact launches or behaves correctly outside the Editor. Record launch, platform performance, signing, distribution, and release acceptance as separate evidence entries.
A standalone player-launch receipt can prove that the exact artifact started, loaded an included scene, passed named project-owned readiness checks, and exited cleanly under a bounded probe. It does not prove physical or user input, rendered-frame correctness, representative performance, distribution, or human acceptance unless those are independently observed.
Durable Evidence Receipt
Create a durable receipt only when a named handoff, audit, comparison, CI, release, or recurring-risk consumer needs one. Ordinary work may report the same facts in the conversation, change record, test output, or commit. When a receipt is justified, record:
- claims made;
- evidence collected for each claim;
- provenance, scope, source revision, and effective toolchain;
- evidence not collected and why;
- human-reviewed aspects;
- remaining uncertainty;
- rollback point.