1527. Lesson identity
1528. Learning objective
After this lesson, you can classify an overall post-release operating context as either bounded post-release maintenance or a live-ops operating model, identify the responsibilities involved, and justify your decision with evidence about recurrence, ownership, monitoring, player-facing coordination, incident handling, or service commitments.
1529. Why this matters
A released game creates additional work, but not every post-release task requires a live-ops model. Treating every fix, patch, content change, or incident as the same kind of operation obscures ownership and encourages unnecessary commitments. A precise boundary helps a team decide what must be scheduled, monitored, communicated, or prepared for recurrence. It also gives AI a constrained operating brief instead of an ambiguous request to “keep the game running.”
1530. Prior knowledge
You should be able to use the ship/no-ship memo from 4.1 L3 — Write the ship/no-ship memo. In particular, you should be able to identify a named build, its release state, the evidence supporting a decision, and the thresholds that make a release acceptable.
1531. Core concept
Live ops is an operating model, not a synonym for post-release bug fixing.
Use two distinct levels of analysis:
- Operating context: classify the overall situation as bounded post-release maintenance or as a live-ops operating model.
- Responsibilities: identify which kinds of work occur inside that context.
A bounded post-release maintenance context addresses a finite correction or compatibility need without establishing recurring operational coordination, ongoing player-facing activity, or an explicit response commitment.
A live-ops operating model establishes repeatable ownership, decision paths, evidence, and commitments for a game already available to players. It can contain four connected areas of responsibility:
- Maintenance: keeping the released game functional through fixes, compatibility work, monitoring, and routine upkeep.
- Content operations: planning, configuring, testing, activating, and retiring time-bound or recurring player-facing content.
- Incident response: detecting, assessing, containing, communicating, and recovering from an unexpected player-impacting problem.
- Service commitments: explicit promises about availability, support windows, response expectations, communication, or the behavior of an ongoing service.
These four areas are responsibilities, not competing classifications of the overall context. Maintenance can occur in either context. For example, a finite compatibility patch can be bounded maintenance, while a configuration correction made during an active event incident is a maintenance responsibility inside live ops.
The size of a change does not determine its context. A small configuration change can belong to live ops if it is part of scheduled player-facing activity with defined activation, monitoring, communication, and rollback decisions. A large one-time compatibility fix can remain bounded maintenance if it creates no continuing operational relationship or service commitment.
1532. Mental model
Apply the model in this order.
Step 1: Classify the operating context
| Operating context | Boundary test | Typical evidence |
|---|---|---|
| Bounded post-release maintenance | Is this a finite correction with a clear end and no recurring operating relationship or explicit service commitment? | Defined fix scope, compatibility check, regression result, closure condition |
| Live-ops operating model | Does this require recurring coordination, active player-facing operation, monitoring, an incident path, or an explicit response or communication commitment? | Schedule, recurring owner, activation or rollback decision, incident record, communication plan, support commitment |
Step 2: Identify responsibilities within that context
| Responsibility | Diagnostic question | Typical evidence |
|---|---|---|
| Maintenance | What keeps or restores the released product's intended function? | Fix scope, compatibility check, regression result |
| Content operations | What player-facing content is being prepared, activated, managed, or retired? | Content specification, schedule, activation and retirement conditions |
| Incident response | What happens when an unexpected player-impacting problem occurs? | Detection signal, severity, owner, containment action, recovery record |
| Service commitments | What has the team explicitly committed to provide or communicate? | Support window, response target, availability statement, communication plan |
The operating context receives one classification. The responsibilities may be multiple.
1533. Concrete examples
Example A: bounded post-release maintenance
A platform update breaks controller input. The team reproduces the problem, prepares a compatibility patch, runs regression checks, publishes the correction, and closes the work. There is no recurring schedule, active player-facing content operation, or explicit ongoing response commitment.
- Operating context: bounded post-release maintenance
- Responsibilities: maintenance
- Evidence: finite correction, regression evidence, and a defined closure point
Example B: live ops with several responsibilities
A weekend challenge changes available objectives and rewards. The team validates the configuration, activates it at a defined time, follows player reports, decides whether to pause or roll it back, communicates material changes, and retires it afterward.
- Operating context: live ops
- Responsibilities: content operations and any applicable service commitments
- Evidence: scheduled activation, active monitoring, operational decisions, and planned retirement
During the challenge, an incorrect configuration awards the wrong item. The team disables the challenge, assesses the impact, communicates the status, corrects the configuration, validates recovery, and restores the activity.
- Operating context: live ops
- Responsibilities: maintenance, content operations, and incident response; service commitments also apply if an explicit communication or response promise exists
- Evidence: an active player-facing operation, containment, impact assessment, correction, communication, and recovery
The correction is maintenance work, but it is not classified as ordinary maintenance because it occurs inside an active live-ops context.
1534. Common mistakes
Mistake 1: mixing classification levels
Calling an incident “both ordinary maintenance and live ops” combines an overall-context label with an embedded responsibility. Instead, classify the context once and then list every responsibility present.
Mistake 2: classifying by implementation effort
“Small means maintenance; large means live ops” is unreliable. Use recurrence, ownership, monitoring, player-facing coordination, incident handling, and explicit commitments as evidence.
Mistake 3: assuming live ops requires constant new content
A live-ops model does not automatically require frequent content releases. Its defining feature is repeatable operational responsibility. The next lesson will ask you to choose the smallest responsible model rather than assume that every game needs the same commitments.
1535. Guided practice
For each scenario, complete both levels of analysis:
- Classify the overall operating context as bounded post-release maintenance or live ops.
- Identify all relevant responsibilities: maintenance, content operations, incident response, and service commitments.
- Give one evidence-based reason for the context classification.
| Scenario | Expected context | Responsibilities to examine |
|---|---|---|
| A platform update breaks controller input. The team prepares and validates one compatibility patch, then closes the work. | Bounded post-release maintenance | Maintenance |
| A monthly mission is configured, tested, activated, monitored, and retired according to a published calendar. | Live ops | Content operations; service commitments if the calendar constitutes an explicit commitment |
| A scheduled mission awards the wrong item. The team disables it, assesses affected players, communicates the status, corrects the configuration, and restores the mission. | Live ops | Maintenance, content operations, incident response, and any applicable service commitments |
| The team reviews crash reports every week and maintains a documented escalation path for severe player-impacting failures. | Live ops | Maintenance and incident response; service commitments only if an explicit promise exists |
Do not infer a service commitment merely because work occurs. Identify one only when the scenario supplies an explicit promise, response expectation, support window, or communication obligation.
1536. Validation and evidence
Complete the attached practical assessment. Your response must include:
- one operating-context classification;
- every relevant responsibility;
- one or two sentences citing concrete scenario evidence.
A strong response keeps the two levels separate, does not classify an embedded correction as ordinary maintenance when the overall situation is live ops, and does not invent commitments absent from the scenario.
1537. Key takeaways
- First classify the overall context; then identify its responsibilities.
- The two contexts are bounded post-release maintenance and a live-ops operating model.
- Maintenance, content operations, incident response, and service commitments are responsibility areas that can exist within a live-ops context.
- Maintenance work can occur inside live ops without making the overall situation “both.”
- Recurrence, ownership, monitoring, player-facing coordination, incident handling, and explicit commitments provide stronger evidence than implementation size.
1538. Next lesson
Continue to 4.2 L2 — Choose the smallest responsible operating model.
1539. Knowledge check
Answer these items for yourself before reading the answers.
Which statement best defines live ops?
Show answer and feedback
Answer: A repeatable operating model for maintaining a released game, managing its operations, and responding to player-impacting problems.
Why: Live ops establishes repeatable responsibilities, decision paths, evidence, and commitments around a released game. It is not every post-release fix and does not require a fixed content cadence.
Which situation is most clearly a bounded post-release maintenance context?
Show answer and feedback
Answer: Preparing and closing a one-time compatibility patch with no continuing schedule or service commitment.
Why: A finite compatibility correction with a defined closure point and no ongoing operating relationship is bounded maintenance. The other situations involve recurring or active operational responsibilities.
Why can a small configuration change belong to a live-ops context?
Show answer and feedback
Answer: Because it may require scheduled activation, monitoring, communication, and rollback decisions while players interact with it.
Why: The operating context, not the size of the implementation, determines the classification. A small change can require recurring or active player-facing coordination.
How should a team analyze a scheduled mission that awards the wrong item, is disabled, and triggers communication with affected players?
Show answer and feedback
Answer: Classify the context as live ops and identify maintenance, content-operations, and incident-response responsibilities.
Why: The active scheduled mission, containment, impact assessment, communication, correction, and recovery place the overall situation in a live-ops context. Correcting the configuration is a maintenance responsibility within that context, while disabling and recovering the mission involve content operations and incident response.