Game Infrastructure Engagement Boundaries
A reference for scoping build, source-flow, builder, artifact, server-delivery, and studio-utility work without turning discovery into an open-ended rewrite.
- Last reviewed
- Version
- 1.0
- discovery
- delivery boundaries
- operating model
Game infrastructure work becomes expensive when every nearby problem is treated as part of the same project. A useful engagement begins with one observable delivery outcome and makes the system boundary explicit.
Boundary model#
Use six boundaries to map the work. Not every engagement needs all six.
| Boundary | Questions to answer | Typical evidence |
|---|---|---|
| Source flow | Which changes may enter a build or release branch, and who resolves conflicts? | stream or branch policy, integration queue, review rules |
| Build definition | Which declared inputs produce each target? | build graph, scripts, engine/toolchain versions |
| Builder runtime | How is worker capacity created, replaced, secured, and observed? | image/provisioning source, runtime identity, health signals |
| Cache and artifact | What is reusable state, what is release evidence, and how is each retained? | cache policy, artifact manifest, checksums, retention rules |
| Promotion | What proves a candidate is compatible and safe to distribute? | smoke evidence, compatibility ID, approval and rollback boundary |
| Operational handoff | Who owns failures after delivery, and what can they recover without the implementer? | runbook, alerts, ownership map, recovery exercise |
Discovery outputs#
Discovery should produce decisions, not a generic audit deck. The minimum useful output is:
- a current-state delivery-path diagram;
- the primary failure mode and its operational cost;
- a written input/output contract for the affected boundary;
- the proposed change, explicit non-goals, and owner;
- acceptance tests and recovery tests;
- dependencies, access requirements, and rollback plan.
If the team cannot agree on the failure mode or acceptance test, implementation is premature.
What stays out of scope by default#
Unless the agreed outcome requires it, the following are separate decisions:
- replacing the studio’s CI orchestrator;
- redesigning all streams or branches;
- migrating every builder at once;
- changing engine versions;
- rewriting game code to accommodate infrastructure;
- replacing DCC tools;
- assuming permanent production operations;
- broad cloud-cost work unrelated to the delivery path.
A bounded project may expose one of these as the next bottleneck. That creates a new decision, not silent scope expansion.
Access and safety#
Begin read-only whenever possible. Write access should be time-bounded, attributable, and limited to the system under change. Production credentials do not belong in build definitions, images, documentation, or handoff bundles.
Before changing a shared delivery path, record:
- current owners and escalation path;
- affected teams and release windows;
- backup or rollback mechanism;
- protected branches, streams, artifacts, and environments;
- how success and failure will be observed.
Acceptance contract#
An engagement is complete when the agreed outcome is observable and the studio can operate the result. Typical acceptance evidence includes:
- a clean worker produces the expected target from declared inputs;
- failed capacity can be replaced through the documented path;
- artifacts carry source and compatibility identity;
- incompatible client/server candidates cannot promote together;
- the highest-risk handoff has an owner, check, and recovery runbook;
- a studio operator completes the recovery exercise without hidden implementer state.
Handoff checklist#
- Architecture and delivery-path diagrams match the implemented system.
- Build, promotion, and recovery commands are versioned.
- Runtime credentials are external to source and images.
- Dashboards and alerts identify an owner and expected response.
- Known limitations and deferred boundaries are explicit.
- The studio has a tested rollback or replacement path.
- Follow-up ownership and support duration are written down.
The purpose of the boundary is not paperwork. It keeps the work attached to a result the studio can verify, recover, and own.