Skip to main content

Research Foundations

STAGE is a synthesis of established practices and emerging agentic-development evidence. It should not be presented as a scientifically proven whole until it has been independently evaluated.

Established Lineage​

  • Data-driven and model-driven design inform the separation of authored intent from runtime realization.
  • Dependency inversion and ports-and-adapters inform explicit integration boundaries.
  • Functional-core and imperative-shell thinking informs deterministic rules surrounded by engine effects.
  • Domain-driven design informs shared vocabulary and explicit model ownership.
  • Observability and continuous verification inform diagnostics and evidence selection.
  • Mixed-initiative co-creativity informs collaboration in which humans and computational systems can both take initiative.

Relevant Work​

Human Control And Progressive Formalization​

Several established lines of work constrain how STAGE should package agentic game engineering:

  • Horvitz, Principles of Mixed-Initiative User Interfaces, 1999, argues for coupling automated services with direct manipulation rather than treating automation and user control as competing endpoints.
  • Amershi et al., Guidelines for Human-AI Interaction, 2019, validated 18 guidelines with 49 design practitioners across 20 AI-infused products. The guidance includes making capabilities clear and supporting efficient invocation, correction, dismissal, and adaptation.
  • Shipman and McCall, Supporting Knowledge-Base Evolution with Incremental Formalization, 1994, demonstrates that useful informal work can precede and progressively acquire formal structure instead of requiring full representation up front.
  • Johnson et al., Coactive Design, 2014, centers interdependence and the practical requirements of observability, predictability, and directability in human-machine joint activity.
  • Bainbridge, Ironies of Automation, 1983, shows that automation can expand the operator's supervisory and abnormal-recovery problems instead of eliminating them.

STAGE applies this lineage by making one project-native accepted change the primary operation. Maps, formal manifests, stable agent interfaces, custom diagnostics, and durable evidence are added only when observed coordination or correction cost or a named consumer gives them a job. Player- or editor-facing features such as galleries remain ordinary project work rather than STAGE infrastructure. This is a design rationale, not empirical proof that STAGE's exact loop is optimal.

Instruction Economy And Normative Restraint​

STAGE's early revisions treated many good practices and hard-won corrections as universal requirements. That made the method more explicit, but also made its default agent context long, repetitive, and expensive to change. Several primary sources argue for a stricter complexity budget:

  • RFC 2119 states that normative imperatives should be used sparingly and only where interoperability or potential harm requires them. Architecture heuristics and preferred work sequences do not automatically meet that bar.
  • Anthropic's Building effective agents reports that successful agent implementations tend to use simple, composable patterns. It recommends beginning with the simplest sufficient solution, making agent-computer interfaces clear, and adding complexity only when measured outcomes justify it.
  • Anthropic's context-engineering guidance frames context as a finite resource whose utility must be curated. STAGE applies that idea through short routing metadata and conditional references rather than loading every edge case into every task.
  • OpenAI's practical guide to building agents recommends incremental orchestration, beginning with a single agent and introducing guardrails in response to observed risks. That supports a small safety kernel plus earned optional contracts rather than a preloaded workflow framework.
  • Gloaguen et al.'s evaluation of repository-level context files found no significant success improvement in the evaluated coding tasks and observed more cost and tool activity when context files were present. The study does not cover Unity or long-running human-agent game development, but it is direct evidence that instructions can be followed while still making work less efficient.
  • Lulla et al.'s study of AGENTS.md efficiency reports a conflicting result across 10 repositories and 124 reconstructed pull-request tasks: the context-file condition had 28.64% lower median runtime and 16.58% lower median output-token use with comparable completion behavior. Its completion check was a coarse sanity check rather than a task-specific correctness evaluator, so it is evidence about operational association, not proof that repository instructions improve patches.
  • Shepard and Albrecht's probe-and-refine study reports that guidance tuned through synthetic bug-fix probes outperformed both its static starting guidance and an unguided baseline for one model and benchmark setup, mainly by increasing the number of evaluable patches rather than per-patch precision. The tuning loop degraded with a less capable model. This supports task-local probing and model-aware guidance maintenance while remaining a recent preprint on software repair, not game-development proof.
  • Xia et al.'s Agentless shows that a simple localization, repair, and validation design can be a strong software-repair baseline. Yang et al.'s SWE-agent shows that a deliberately designed agent-computer interface can materially affect performance. Together they support improving concrete project interfaces while resisting a large universal process layer.

The evidence does not establish one optimal prompt length or prove that all repository guidance is harmful. It does justify a falsifiable default: keep universal requirements to human authority and harm prevention; keep interoperability rules with the optional artifact that needs them; expose specialized guidance only when the current claim needs it; and measure before adding another permanent instruction. Conflicting results are a reason to measure guidance against complete task outcomes, not a reason to select the study that best matches a preferred method.

Two recent evaluation papers sharpen that restraint without directly proving a STAGE rule. Mustahsan et al.'s Stochasticity in Agentic Evaluations shows substantial within-query variation and reports that stable estimates can require repeated trials whose count depends on task structure. Orlanski et al.'s SlopCodeBench finds that iterative test success can coexist with growing verbosity and structural erosion, and that a prompt intervention improved initial quality without stopping later degradation. Together they support repeated measurements plus artifact-level structural review. They do not establish a universal replication count, prove that STAGE prevents erosion, or make prompt length a quality metric.

Bounded Search, Information Scent, And Oversight Cost​

STAGE's inspection stopping rule combines several relevant but non-equivalent lines of evidence:

  • Lawrance, Bellamy, and Burnett's Scents in Programs and Lawrance et al.'s How Programmers Debug, Revisited apply information-foraging theory to program maintenance and debugging. STAGE uses this as support for beginning from strong source cues and updating the search as evidence changes rather than reading a repository uniformly.
  • Simon's Rational Choice and the Structure of the Environment and later Nobel lecture frame decision-making under bounded knowledge and computation. STAGE borrows the practical idea of stopping at decision sufficiency; it does not claim that software inspection has one mathematically optimal stopping point.
  • Liu et al.'s Lost in the Middle found that then-current language models did not use long context uniformly and could perform worse when relevant information was poorly positioned. This is evidence against assuming that more context is automatically more usable context, not a current-model performance bound or a reason to withhold needed evidence.
  • Dhanorkar, Passi, and Vorvoreanu's exploratory interviews with 17 experienced developers found a priori control, co-planning, real-time monitoring, and post hoc review, while noting that practitioners use efficient rather than perfect oversight. The study provides an early empirical anchor, not a general oversight optimum.
  • METR's early-2025 developer experiment reported a slowdown for experienced open-source developers using the tools available then. Its February 2026 update reports raw later estimates that point toward speedup but explicitly judges them unreliable because participation, task selection, pay, and concurrent agent use distort the signal. STAGE therefore does not treat either result as a timeless productivity claim.
  • METR's algorithmic-versus-holistic evaluation found that automatic tests could overstate merge readiness in a small sample of real tasks. OpenAI's later SWE-bench Verified audit likewise found substantial task and test defects in the audited subset. These findings support validity-aware, human-reviewed evaluation rather than making one static action count or benchmark score the stopping authority.

STAGE's resulting inference is deliberately narrow: inspect while unresolved evidence can still change ownership, implementation, verification, authority, diagnosis, or material risk; otherwise move to the next discriminating action. Conflicting evidence, failed verification, unclear blast radius, unresolved authority, a missing production consumer, or an explicitly broad audit can reopen the search. This rule is a practitioner hypothesis that still needs cross-task and independent evaluation.

Provenance And Operation Authority​

NIST SP 800-162 frames authorization around a subject requesting an operation on an object under policy and environmental conditions. NIST's least-privilege definition limits authorization to what is necessary for an assigned task. Separately, W3C PROV-O models entities, activities, agents, derivation, and attribution. It describes how state came to exist; it does not grant mutation authority.

STAGE infers an operation-granular rule from those distinct models: uncertain provenance in one part of an artifact should constrain nearby work without erasing explicit authority for another exact operation, and authority for that operation must not widen into whole-artifact replacement or regeneration. The standards do not prescribe this game-engineering rule.

The initial safety-boundary study exposed the need for the distinction when a blanket artifact-level evaluator penalized every narrow source-backed repair. The corrected ownership-granularity replication then repeated safe narrow repair and safe broad stopping across character, UI, and audio fixtures. Every condition behaved correctly, so the evidence supports specification precision rather than a STAGE treatment-effect claim.

Verification, Validation, And Complete Claims​

STAGE's consumer-complete verification rule connects several established ideas without treating any one of them as a universal testing prescription:

  • Saltzer, Reed, and Clark's End-to-End Arguments in System Design, 1984, argues that some functions can be implemented completely and correctly only with application-end knowledge. Lower-level mechanisms may still be useful. STAGE applies this as an analogy for evidence scope: a lower layer cannot establish a claim whose decisive context exists at a consumer it bypasses.
  • NASA distinguishes verification from validation: verification establishes compliance, while validation asks whether the product achieves its intended purpose in its intended environment. NASA's Product Realization guidance also recommends anticipated operators or users whenever possible.
  • Google's Testing for Reliability retains unit, integration, system, and production-probe evidence with different cost and scope. Its code-review guidance asks for unit, integration, or end-to-end tests as appropriate and reminds reviewers that tests themselves require human judgment.
  • Unity's Test Framework distinguishes Edit Mode, Play Mode, and target-player execution. Their availability in one framework does not make their evidence scopes interchangeable.

STAGE synthesizes these into a claim-routing rule: identify the production consumer and intended environment, then choose the smallest route that includes all material boundaries. Focused tests remain essential for speed and fault localization. Broader composed evidence is added only where the claim crosses those boundaries, and human product validation remains separate from mechanical verification. This formulation is practitioner guidance, not an empirically proven optimum or a replacement for a project's test strategy.

Feedback Portfolio​

Consumer completeness does not mean running every available test after every edit. A useful portfolio must balance scope with correction speed:

STAGE applies this by separating a fast Safety Kernel gate from named Maintainer Laboratory suites while retaining a complete release gate. The change gate supports only the claims it executes; touched laboratory systems still require their focused suite, and releases require all supported contracts. This is a measured correction to STAGE's own workflow, not a universal test taxonomy.

Case-Study Claim Discipline​

STAGE's external maps and operational trials are exploratory case-study evidence, not independent product endorsements or controlled productivity experiments:

STAGE therefore records immutable source coordinates, operation outcomes, limitations, independence, and target-maintainer review separately. A researcher can accept an external map as useful evaluation evidence while the target maintainer has neither reviewed nor adopted it. Mapping a materially different project supports analytical transfer of the mapping vocabulary to that case; it does not prove faster orientation, safer changes, or lower maintenance cost. Those stronger claims require their own study designs and human evidence.

Visual Inspection Lineage​

STAGE's direct visual-review workflow and its guidance for project-native inspection features draw on established native inspection, operation, and regression practices:

  • Ben Shneiderman's direct-manipulation lineage emphasizes continuous representation, physical actions or labelled controls, rapid incremental operations, reversibility, and immediately visible impact. A live native viewport with nearby camera, lighting, time, and reset controls seeks these properties more directly than an exported evidence package.
  • The GDC session In-Game Debugging and Visualization Tools treats live data visibility, state mutation, history, modularity, and integration with the running game as central debugging-tool concerns. This supports keeping recurring review beside the production state it operates.
  • Unity's Graphics Test Framework renders project scenes in the editor or a player and compares them with reference images. Its authoring workflow treats the first result as a candidate that a human inspects before it becomes the reference.
  • Unreal Engine separates its native Automation Test Framework, Automation Driver, and Screenshot Comparison Tool. Engine execution, input operation, and human-reviewed screenshot comparison are related capabilities rather than one undifferentiated gallery.
  • Unreal's Animation Editors combine asset browsing, a live viewport, playback, and Preview Scene Settings; its saved Preview Scene Profiles expose lighting, environment, floor, post-processing, and rotation without requiring a separate reporting surface. This supports STAGE's use of native, human-owned presentation profiles and its rule to avoid custom tooling for a one-off question already served by the engine.
  • Unity's Animation window previews authored clips beside the selected project object, while Visual Effect Graph can preview an effect in the Inspector or as a scene instance. These asset-local surfaces are first-class review hosts. A custom runtime gallery is justified only when it independently serves a recurring product, authoring, or development job that existing surfaces cannot serve cheaply.
  • Godot's editor plugin and main-screen plugin guidance shows how project-owned scenes and UI can extend the native editor while retaining explicit entry, exit, and cleanup lifecycle.
  • Storybook's story browser and testing guidance demonstrate the value of named component states that serve interactive development and testing without turning the browser itself into a shipping product surface.
  • Playwright's snapshot guidance documents that image baselines depend on operating system, settings, and hardware and therefore need controlled environments and review.
  • Procedural-content evaluation research distinguishes quality, diversity, and controllability rather than reducing generated output to one score; relevant examples include PCG Benchmark, Procedural Content Generation via Generative Artificial Intelligence, and Procedural Content Generation: Goals, Challenges and Actionable Steps.

STAGE's synthesis is to connect these practices to explicit human/agent entry points, engine-owned content discovery, plain claims about which production consumer and context a native view includes, lifecycle ownership, and exports only for named consumers. Google's large-scale study of architectural complexity and maintenance burden reports correlation between architectural complexity, bug-fix work, and negative developer sentiment across more than 1,200 projects and 7,200 survey responses. It does not establish causality, but it strengthens the reason to remove an unconsumed parallel metadata architecture rather than preserving it for hypothetical future users.

Developer inspection, operation, regression, player presentation, and export remain separate responsibility contracts. When a project independently builds a codex, gallery, bestiary, model viewer, world previewer, or inspect mode for a real user, it can share production resolution, staging, rendering, and playback where useful without becoming a STAGE requirement. That synthesis remains a practitioner proposal, not proof that one visual workflow fits every engine or game. STAGE infers that in-context direct manipulation is the better default for this problem; it does not claim that every project needs persistent inspection UI or that native UI alone guarantees truthful review.

Game Design, Automated Play, And Human Experience​

STAGE's engineering evidence boundary also needs a gameplay-design boundary. Established game-design frameworks can improve the questions an agent asks without making the agent an authority on the desired experience:

  • Hunicke, LeBlanc, and Zubek's MDA framework connects mechanics, runtime dynamics, and desired player aesthetics. It explicitly distinguishes designer and player perspectives, encourages experience-driven rather than feature-driven design, and rejects the idea of a universal formula for fun.
  • Sweetser and Wyeth's GameFlow integrates heuristics around concentration, challenge, skill, control, clear goals, feedback, immersion, and social interaction. Its initial validation used expert review of two games; STAGE therefore treats it as a critique lens, not a product acceptance score.
  • Ryan, Rigby, and Przybylski's self-determination theory studies use human studies to connect autonomy, competence, and relatedness with enjoyment and future play. Those constructs concern experienced need satisfaction, not properties that source inspection can establish.
  • Abeele et al.'s Player Experience Inventory was developed with expert and player studies and measures functional and psychosocial consequences through player report. An agent can help administer or analyze it but cannot answer it on a player's behalf.
  • Medlock et al.'s RITE method supports rapid changes after observed human usability problems and empirical rechecking of those changes. Its loop depends on actual participants.
  • Holmgard et al.'s procedural-persona playtesting demonstrates useful automated exploration through encoded archetypal policies. The surprising behavior of those agents also illustrates that the result follows the utility function, observations, and action space supplied.
  • Microsoft's Applied User Research in Games frames games user research as the adaptation of social-science methods to evaluate and improve usability and enjoyability.

The resulting STAGE boundary is conservative. Agents directly verify rules, state, distributions, encoded policies, and bounded presentation mechanics. They may generate hypotheses about likely clarity, pacing, balance, fairness, or accessibility. Human designers choose intended experience and acceptable tradeoffs. Direct human play establishes lived interaction claims, and broader audience claims require representative target players. Telemetry shows what happened; observation and self-report help establish how and why it was experienced. No theory checklist, synthetic agent, or automated playthrough computes fun.

The operational guidance is in Human-Led Gameplay Design. The more detailed Systems-Heavy Gameplay Evidence guide adds decision, feedback, UI, learning, pacing, progression, balance, accessibility, ethics, and playtest lenses.

That guide uses a proposed perceive -> decide -> act -> read consequence -> learn -> adapt trace. The trace synthesizes established concerns; it is not a validated psychometric instrument or universal design sequence. In particular:

  • meaningful-choice research supports examining perceived alternatives and consequences, but does not imply that every moment needs a choice or that more options are better;
  • direct-manipulation and ecological-interface work support visible state, direct action, constraints, and causality, but do not prescribe one UI style;
  • game-feel and juiciness research support timely, layered feedback while also showing that maximal feedback is not automatically better;
  • onboarding studies support testing the actual first-time experience and integrating instruction with play, not one universal tutorial form;
  • strategy search, telemetry, and balancing tools expose mechanical risks under encoded assumptions; they do not establish perceived fairness, meaningfulness, or enjoyment;
  • accessibility guidelines identify recurring barriers and useful design practices, while lived usability remains population- and context-dependent; and
  • engagement metrics can describe behavior without proving player welfare or justifying coercive design.

This synthesis is informed by established work but remains a STAGE practitioner decision rather than a scientifically validated universal method.

Distinct Proposed Contribution​

No individual STAGE primitive is new. The proposed contribution is a game-engineering method that treats the following as one production system:

  • domain and runtime architecture;
  • human and agent decision rights;
  • authoring and operation tools;
  • manual and generated ownership;
  • multimodal evidence and rehearsal;
  • reversible source-control practice.

External studies now support the narrower claims that this combination can map materially different architectures, surface unsafe ownership assumptions, and make evidence-scope mismatches explicit. The stronger hypothesis—that STAGE reduces the human attention required to obtain and maintain trustworthy changes—still requires independent controlled changes and longitudinal adoption.

See Cross-Project Case-Study Synthesis for the observed evidence and its limits.

Last updated on