STAGE Core Specification

Version: 0.6 Status: Evidence-bounded practitioner proposal

1. Purpose

STAGE is a human-directed method for agent-assisted game engineering. It aims to make changes safer to delegate, easier to inspect in the real project, and more honestly verified without prescribing a game architecture or requiring a STAGE artifact.

The method is organized into three layers:

1. a small universal Safety Kernel;
2. a recommended project-native delivery loop; and
3. optional interoperability contracts for projects that deliberately adopt maps, named operations, structured ownership, or durable evidence records.

STAGE is not an engine, runtime framework, maturity model, autonomous developer, or guarantee of product quality. Its exact workflow has not been independently or longitudinally validated. See Research Foundations and Evaluation for the evidence boundary.

2. Requirement Language

The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are interpreted as described by RFC 2119. They are used only for the universal Safety Kernel or an explicitly adopted interoperability contract.

Text outside those sections is guidance. A project may choose another safe architecture or work sequence without violating STAGE. Requirement language in an optional contract applies only when a project declares that contract.

3. Universal Safety Kernel

These rules apply whenever a change is described as STAGE-directed. They protect human authority, project state, and the truthfulness of engineering claims; they do not require a specific file, tool, engine, or architecture.

S1. Direction And Authority

The newest authorized human outcome MUST govern the active work. A diagnosis-only request or explicit rejection of a route MUST NOT be turned into unauthorized implementation of that route or a nearby substitute. Final authority over product intent, taste, destructive actions, publishing, and acceptance MUST remain with the accountable human.

S2. Protected State

Pre-existing, unrelated, and human-authored work MUST be preserved unless its modification is explicitly authorized. An agent MUST NOT reset, regenerate, normalize, delete, or replace uncertain work merely to simplify the task.

S3. Fail Closed On Material Uncertainty

When authority for a proposed mutation, its destructive scope, credentials, publication rights, or another material authority boundary is unresolved, that mutation MUST NOT proceed. Authority for one named operation MUST NOT be widened to adjacent state, replacement, or regeneration. Unresolved provenance elsewhere in an artifact does not by itself prohibit a separately authorized operation that preserves that state. The agent may inspect safely or request the smallest missing decision; it MUST NOT infer permission from convenience, similarity, or generic continuation language.

S4. Canonical Source And Real Consumer

Material changes MUST use the project's canonical source or authoring path. A claim about integrated behavior MUST be checked through a route that includes the real production consumer and every boundary material to that claim. A substitute preview or harness MUST NOT be presented as proof of a production context it omits.

S5. Claim-Matched Evidence

Evidence MUST be reported only for the scope it actually exercises. Compilation and static checks MUST NOT be presented as proof of runtime composition, visual quality, audio quality, game feel, balance, performance, or player usability. Automated tests and agent judgment MUST NOT replace human acceptance of subjective product qualities.

S6. Truthful Outcomes

Failed, unavailable, skipped, stale, or inconclusive verification MUST be reported as such. A command or tool result MUST NOT be called passed when its real exit status is unknown or when the current invocation did not produce the claimed completion signal.

S7. Reversibility

Broad, destructive, or high-risk experiments MUST begin from a recoverable checkpoint or an equivalently safe boundary. Rejection and rollback MUST remain valid outcomes; sunk cost MUST NOT be used to continue a rejected route.

S8. Read-Only Claims

An external inspection described as read-only MUST compare the protected source state before and after inspection. Any observed delta MUST be disclosed. Tools likely to import, compile, or generate state SHOULD run in a disposable copy when source immutability is material to the claim.

4. Recommended Practice

This section is deliberately non-normative. It describes the STAGE default, not a conformance checklist.

4.1 The Five Qualities

• Systems-oriented: important behavior has discoverable ownership, state, rules, and lifecycle.
• Tool-mediated: work uses the authoritative project, engine, middleware, and source-control paths; custom tools are added only for a real recurring job.
• Agent-operable: a delegated change path is legible and safely actionable; this does not mean every domain needs an API.
• Governed: humans direct the product and retain meaningful correction, rejection, and rollback authority.
• Evidence-backed: the evidence type and scope match the claim being made.

These are design questions, not required module boundaries. MonoBehaviours, ECS, data-oriented systems, plain objects, scripts, scenes, nodes, resources, and custom engines can all support them.

4.2 Delivery Loop

The default loop for one material change is:

Frame -> Inspect -> Plan -> Build -> Rehearse -> Judge -> Checkpoint
  ^                                               |
  +---------------- tune or revert ---------------+

• Frame the player, author, or maintainer outcome, non-goals, authority, and acceptance boundary.
• Inspect the smallest real path through source, authored content, composition, runtime, and presentation that can change the next decision.
• Plan the smallest complete result and the evidence needed for its claims.
• Build through canonical project sources while preserving unrelated state.
• Rehearse through the smallest route that contains each production consumer and material integration boundary.
• Judge mechanical evidence separately from human product judgment.
• Checkpoint accepted work, or tune, diagnose, defer, or revert.

The loop is a useful default, not mandatory ceremony. Small changes may combine steps. Diagnosis may end after inspection. A large change may repeat the loop many times.

4.3 Inspection Lens

For a material domain, it is often useful to ask:

Lens	Question
Intent	What can a human author or tune?
Runtime	What mutable state exists, and who owns its lifecycle?
Behavior	Which rules change that state?
Integration	Which engine or middleware boundary performs side effects?
Operation	How can the relevant state be exercised or inspected?
Evidence	What route can truthfully support the current claim?
Ownership	Which artifacts are human-authored, generated, external, or ephemeral?

Use project vocabulary and existing architecture first. Missing reference roles are not defects by default. Add an abstraction only when it solves observed complexity, duplication, ownership risk, or a real repeated operation.

4.4 Decision-Sufficient Inspection

Begin from the concrete change or diagnosis and follow the strongest source cues. Continue inspecting while another observation can plausibly change ownership, implementation, evidence, authority, diagnosis, or material risk. Stop when the next engineering decision is supported. Conflicting evidence, failed verification, unclear blast radius, or an explicitly broad audit can justify expansion.

There is no universal file, command, token, or time quota. More context is not automatically better context.

4.5 Earned Infrastructure

Start with the direct project-native route. Persist a map, helper, abstraction, custom operation, diagnostic, export, or product surface when an observed recurring cost, material ownership risk, or named consumer gives it a durable job. Retire it when it no longer shortens or safeguards the real change loop.

A codex, gallery, bestiary, model viewer, world previewer, or inspect mode is an ordinary game or authoring feature. Build one when players, authors, or developers need that feature; do not manufacture it merely as STAGE evidence. Screenshots and video are useful when a remote reviewer, comparison, CI check, audit, release, or retention decision needs portable output.

4.6 Visual And Experiential Work

Rendered appearance, animation, VFX, UI, lighting, audio, feel, pacing, and procedural readability should be judged in the real engine or game with the production content and relevant context. Fixed seeds and repeatable states can improve comparison. Human judgment remains the acceptance authority.

See Visual Work and the Task-Evidence Matrix for claim-specific guidance.

4.7 Player-Facing Expansion Gate

When work originates or materially expands a player-facing loop, first frame a small experience hypothesis and build one complete playable slice. Human play of the real player surface should separately judge comprehension, usability, engagement, and desire to continue. A blocked or untested loop should remain a bounded iteration rather than becoming the basis for broad architecture, content, modes, polish, or transferability claims.

This is a high-leverage product checkpoint, not a requirement for every bug fix, refactor, or content change. Human acceptance is project-local direction, not proof of objective fun or market fit.

5. Optional Interoperability Contracts

The contracts below are independent. A project adopts only those it uses. Their requirements standardize artifacts exchanged between people or tools; they do not impose a runtime architecture.

5.1 Project Map Contract

A project declaring the STAGE project-map contract MUST maintain a human-readable map and a machine-readable manifest in the locations declared by the manifest. The manifest MUST declare a supported schema version and map profile, and MUST validate against that version's schema.

The map and manifest MUST identify, proportionally to the selected profile:

• project direction and current phase;
• canonical terminology and important ownership boundaries;
• composition, lifecycle, authoring, and runtime entry points;
• available operations and their readiness boundaries;
• verification routes and experiential decision owners; and
• unresolved authority, prohibited actions, and known high-risk workflows.

The map MUST NOT duplicate volatile test counts, timestamps, hashes, or run outcomes as if they were durable architecture. It may link to a canonical revision-bound record. Compact projects MUST NOT manufacture domains or operations merely to fill a template.

5.2 Named Operation Contract

A project declaring a named operation MUST identify its purpose, capabilities, preconditions, expected effects, safety class, completion signal, and supported evidence claim.

Operation state uses these meanings:

• documented: instructions exist; availability was not established;
• available: required capabilities and readiness were observed;
• passed or failed: the current invocation produced a conclusive result;
• inconclusive: execution did not answer the intended claim;
• unavailable: a required capability or state was absent; and
• not attempted: execution was intentionally omitted.

An operation definition MUST NOT be presented as execution evidence. A wrapper MUST preserve the real failing status. passed MUST require the declared completion signal from the current invocation; stale output or process exit alone MUST NOT be reused as current proof.

5.3 Ownership Record Contract

A structured ownership record MUST use its declared schema vocabulary or a documented project refinement. Generated authority MUST identify its source and regeneration operation. Unresolved authority MUST identify a decision owner and prohibited mutations. Automation MUST NOT regenerate, delete, or normalize unresolved artifacts.

The current STAGE vocabulary is:

Authority	Meaning
human	Project-owned source, tuning, data, or assets.
project-generated	Reproducible output from project-owned tooling.
external-generated	Output from middleware or another authoring tool.
external-vendored	Tracked third-party material with an upstream owner.
runtime	Ephemeral state, not authored project intent.
legacy	Retained material with a known non-current role.
unresolved	Authority is insufficient for broad automation.

Human-facing labels in this specification use spaces or hyphens. Project-map 0.3 wire values encode the same concepts with exact snake_case schema enums, including not_attempted, project_generated, external_generated, and external_vendored; those spellings are not project refinements.

5.4 Evidence Record Contract

A structured evidence record MUST identify the claim, evidence class, outcome, and material scope. It SHOULD include provenance, source revision, effective toolchain, limitations, and unresolved uncertainty when those affect reproducibility or interpretation.

When a versioned artifact represents those coordinates across linked records, one claim linkage MUST carry the outcome and nonblank material scope and resolve to its evidence class. Coordinates borrowed from different claims do not form one evidence record.

An outcome-free supported claim or verification route is a definition, not an execution evidence record, and MUST NOT be reported as proof that the route ran or answered its claim.

Supported evidence classes include static, deterministic, composed runtime, observed runtime, visual, interactive, and experiential evidence. One class or scope MUST NOT be reported as another.

5.5 External Study Contract

A STAGE external study MUST identify its target, immutable source revision, inspection basis, researcher disposition, and target-maintainer review status separately. Observations, inferences, proposals, and normative claims MUST remain distinguishable. A researcher MUST NOT grant target-maintainer acceptance or imply adoption that did not occur.

5.6 Artifact Compatibility Contract

Versioned STAGE artifacts MUST declare their schema version. Tooling MUST select that declared version, MUST NOT silently rewrite a supported older artifact, and MUST make migration explicit and reviewable. Migration MUST preserve human decisions; unsafe legacy ownership mappings MUST remain unresolved.

Project-map schemas 0.1 and 0.3 and case-study schemas 0.1, 0.3, and 0.4 remain supported by STAGE 0.6. The method release and artifact schema version are independent.

6. Reporting STAGE Use

Do not report an aggregate STAGE conformance score or maturity level. Instead, state the bounded facts:

• the change or revision to which STAGE 0.6 was applied;
• which Safety Kernel rules were material;
• which optional contracts, if any, the project declared;
• which evidence was actually collected; and
• which checks or human judgments remain unavailable, rejected, or pending.

Applying more optional contracts does not imply better architecture, product quality, autonomy, or agent readiness.

7. Scope And Non-Goals

STAGE does not prescribe:

• a game engine, programming paradigm, dependency-injection framework, or data format;
• one domain decomposition or file layout;
• custom agent APIs, project maps, evidence packages, galleries, or automation;
• fully autonomous development; or
• a replacement for design judgment, playtesting, profiling, accessibility evaluation, security review, or platform certification.

The project's own language, architecture, engine conventions, and accountable humans remain primary. Reference profiles are question sets and worked examples, not target shapes a project is expected to imitate.