Live service and updates

Rubric components

Components describe the mechanic as observed. Each is scored from 0 to 4, or marked unknown or not applicable. The final level reflects the overall pattern, not an average. Component-level definitions are not stored in the database; they remain in the methodology’s source document.

• Release cadence

  How consistent the gaps between meaningful releases are within the observation window: release count, median gap, and longest gap.

• Release announcements

  How far in advance the next release is known and whether announced dates are met.

• Content scope and type

  What is released: fixes, additions to existing systems, expansions, reworks, and major releases. The content source is recorded alongside it.

• Seasonal structure

  A recurring seasonal framework with its own content, goals, and reset or carry-over rule. A season from a neighboring module does not count.

• Event calendar

  Time-limited activities with their own gameplay content, schedule, and return pattern.

• Roadmap transparency

  How public the roadmap is and how dated changelogs compare promises with delivery. The roadmap direction is recorded alongside it.

• Response to players

  Dated pairs of public player feedback and a resulting change, along with public tests and reports.

• Game integration

  How strongly updates change core game loops and shape the player's routine.

Final level steps

All steps are shown, including those with no games. At levels 1–5, zero means no matching games were found; it is different from an unassessed step. A game with multiple scopes at different depths appears at each relevant step, so totals can exceed the number of assessed games. Required conditions for levels 3–5 are documented outside the database.

The first count shows games with an exact result. “No higher than N” results and results with no recorded form are shown separately and are not added to the exact count.

• 0 of 5 — NoneNo assessment has a derived final level

  The game is not being updated: the observation window contains no meaningful releases.

  Level 0 is empty by design. An absent mechanic is recorded through presence, not as depth level 0, and receives no depth level. The mechanics page shows assessment and presence counts.

• 1 of 5 — MaintainedNo assessment has a derived final level

  The game is maintained through occasional small additions and fixes without a cadence or framework.

• 2 of 5 — Periodic updatesNo assessment has a derived final level

  Meaningful releases recur, but there is no schedule, seasonal framework, or calendar.

• 3 of 5 — Structured live serviceNo assessment has a derived final level

  A stable cadence and at least one working framework: a season or event calendar.

• 4 of 5 — Core live serviceNo assessment has a derived final level

  The seasonal cycle and release stream define what players in the segment do, while updates regularly change several core loops.

• 5 of 5 — Continuously reshaped gameNo assessment has a derived final level

  Updates reshape the game itself: its content, rules, and world differ materially from the previous state, and a seasonal or calendar framework is one of the product's main loops.

Module fields

Observations the module requires with each assessment. They help verify that the conclusion follows from the observed implementation. Section names are stored as free text and may reference more than one section.

• Who maintains the game

  The team whose release cadence is assessed. A change in the support team breaks the series, so the field has one value: a second team means a second observation period.

  Value type:

  List, custom values allowed, single value

  Requirement:

  Required

  Methodology section:

  15.3

  Allowed values:

  • Developer
  • Publisher
  • Regional publisher
  • Platform
  • Other — The methodology does not declare this value set closed. The value is meaningful only with an explanation (section 7). (Requires an explanation)
• Date the team began maintaining the game

  After the game moves to another studio, cadence is assessed for the new team and the previous period remains history.

  Value type:

  Date, single value

  Requirement:

  Required

  Methodology section:

  15.3

• Announcement channel

  The channel used to collect releases. A channel that cannot be found produces Unknown, not Absent.

  Value type:

  Text, single value

  Requirement:

  Required

  Methodology section:

  15.3

• Announcement channel completeness

  How much of the window was read and within which boundaries. If the number of first-party announcements reaches the source's sampling limit, the window is not considered complete.

  Value type:

  Text, single value

  Requirement:

  Required

  Methodology section:

  15.3

• Active release framework

  The implementation type whose completed cycles count toward level 4. One game can combine several frameworks, in which case all active ones are recorded (15.2).

  Value type:

  List, custom values allowed, multiple values

  Requirement:

  Required

  Methodology section:

  15.2, 15.3

  Allowed values:

  • Seasonal model — A recurring cycle that resets part of the state.
  • Major paid expansions — Expansions with patches between them.
  • Stream of small releases — A continuous stream without a seasonal framework.
  • Event calendar as the main framework
  • Episodic story chapter releases
  • Early access development under an announced plan
  • Other — The methodology does not declare this value set closed: section 15.2 names implementation categories, not an exhaustive list. The value is meaningful only with an explanation (section 7). (Requires an explanation)
• Release framework change date

  The date when the active framework replaced the previous one.

  Value type:

  Date, single value

  Requirement:

  Required when applicable

  Methodology section:

  15.3

  Required when: When the framework changed within the observation window.

• Observation window start

  The rubric's base window is the 12 months before the observation date. For a game under one year old, the window begins at launch.

  Value type:

  Date, single value

  Requirement:

  Required

  Methodology section:

  15.3

• Observation window end

  The right boundary of the window, usually the observation date.

  Value type:

  Date, single value

  Requirement:

  Required

  Methodology section:

  15.3

• Observation window length, months

  Window length in months. Recorded beside the score because three months of cadence and three years of cadence are different observations.

  Value type:

  Number, single value

  Requirement:

  Required

  Methodology section:

  15.3

• Observation window segments

  A segment's boundaries and the reason for splitting it. A window can have several segments, each recorded separately. The final result uses the segment after the transition, while the level before it remains in history. No single level is derived for a split window.

  Value type:

  Text, multiple values

  Requirement:

  Required when applicable

  Methodology section:

  15.3, 15.7

  Required when: When the release framework changes within the window or support moves to Maintenance, Recurring calendar, Sunset announced, or Ended.

• Support duration at observation date, months

  How many months the game has been maintained as of the observation date. Launch date belongs to the game profile; support duration is an assessment observation.

  Value type:

  Number, single value

  Requirement:

  Required

  Methodology section:

  15.3

• Support state

  The mode state (section 4) for this module, recorded separately from depth. Live service has no separate contour_state because support state is the assessment subject and has its own closed list. Maintenance, Recurring calendar, Sunset announced, and Ended cap levels at 3–5 regardless of earlier cadence. This is not the game lifecycle status. The list is closed because this is a module scale with every value defined (15.5). Unknown is recorded as a reason instead of a value: sources that do not fully cover the window are named in the reason, not as a list key. There is one value: active and ended in one assessment would be a contradiction, not two observations.

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  15.5

  Allowed values:

  • Active support — Active: meaningful releases continue.
  • Slowed support — Slowed: cadence is materially lower than in the previous comparable window.
  • Maintenance without new content — Maintenance: fixes, operational work, and repeats of earlier events and rewards continue.
  • Recurring calendar — Recurring calendar: events and paid bundles repeat, with no new content released.
  • Sunset announced — Sunset announced: releases are limited to what is necessary.
  • Support ended — Ended: there are no releases. This is an observation about cadence, not grounds for a closed game status.
• Meaningful release count within the window

  The first of three release cadence observations. The score cannot be reproduced without all three (15.6).

  Value type:

  Number, single value

  Requirement:

  Required when applicable

  Methodology section:

  15.6

  Required when: Beside the Release cadence component score.

• Median gap between meaningful releases, days

  The median in days. Score 3 requires the longest gap to be no more than twice the median.

  Value type:

  Number, single value

  Requirement:

  Required when applicable

  Methodology section:

  15.6

  Required when: Beside the Release cadence component score.

• Longest gap between meaningful releases, days

  The longest gap in days.

  Value type:

  Number, single value

  Requirement:

  Required when applicable

  Methodology section:

  15.6

  Required when: Beside the Release cadence component score.

• What remains after a release

  Games with the same cadence differ here: one accumulates content while another refreshes it without growing. The list is closed and includes Mixed for all remaining cases (15.6).

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  15.6

  Allowed values:

  • Accumulation — Released content remains in the game.
  • Rotation — Content returns on a recurring cycle.
  • Departure — A temporary activity disappears along with its rewards.
  • Replacement — New content displaces old content.
  • Mixed — Covers cases that do not reduce to one of the other four answers.
• Content source

  The rule that community content does not increase depth applies only to an open stream that the developer neither curates nor releases. Sources can be combined, so all active ones are recorded.

  Value type:

  List, custom values allowed, multiple values

  Requirement:

  Required

  Methodology section:

  15.6

  Allowed values:

  • Work by the support team
  • Curated and released community work — The announced submission set, selection, and release are all support work.
  • Work by an external partner
  • Other — The methodology does not declare this value set closed. The value is meaningful only with an explanation (section 7). (Requires an explanation)
• Frozen framework

  A season extended until server shutdown looks the same as an active one. A frozen framework cannot score above 1 on the component. The list is closed because the attribute is binary.

  Value type:

  List, fixed options, single value

  Requirement:

  Required when applicable

  Methodology section:

  15.6

  Required when: When a season or calendar continues without new content.

  Allowed values:

  • Framework is active
  • Framework is frozen — A season or calendar continues without new content.
• Roadmap direction

  The score measures transparency, not direction: a model shutdown announcement can be as transparent as a growth plan under the component rules. The list is closed: its ordered values cover the full attribute from growth to an announced end (15.6).

  Value type:

  List, fixed options, single value

  Requirement:

  Required when applicable

  Methodology section:

  15.6

  Required when: Beside the Roadmap transparency component score.

  Allowed values:

  • Announced scope is growing
  • Holding steady
  • Shrinking
  • End announced
• Count of dated "public message — change" pairs

  The score uses pairs, not discussion sentiment. The methodology does not explicitly require this count: it names all three release cadence observations (15.6) but not the player response count. The requirement follows from the rubric itself: score 2 requires one pair per window and score 3 requires at least three, so the score cannot be verified without the count.

  Value type:

  Number, single value

  Requirement:

  Required when applicable

  Methodology section:

  15.6

  Required when: Beside the Response to players component score.

• Early access status

  Early access follows the same assessment rules, but the status is recorded beside the score. The list is closed because the attribute is binary.

  Value type:

  List, fixed options, single value

  Requirement:

  Required when applicable

  Methodology section:

  15.1

  Required when: When the game is in early access.

  Allowed values:

  • Early access
  • Full launch

Version history

Changes recorded for each module version. Assessment versions are matched against this history because different rubric versions may produce different levels.

• Version 0.3 Current Adoption date not recorded

  Revised after a six-game pilot over a one-year window. Split "Release cadence and predictability" into "Release cadence" and "Release announcements," and gave cadence an observable threshold: release count, median gap, and longest gap. Rewrote the mandatory level 4 condition around completed cycles of the active framework so a game without seasons is not capped by the rubric design; made level 5 reachable through a dense calendar. Added the Repeat type, content source, roadmap direction, frozen framework, Recurring calendar support state, window splitting when support stops, a rule for framework changes within the window, and a limit on announcement feed depth. A season from a neighboring module no longer counts here.

• Version 0.2Adoption date not recorded

  First written module version: concept, implementation types, assessment scope, meaningful update rule, support state, seven components, final-level rules, usage signals, classification errors, and minimum evidence.

Versions used for recorded assessments

This list is based on assessments, not version history. Versions with no recorded assessments are omitted. Reassessment replaces the previous record, so zero for an older version would misleadingly imply that it was never used.

• Version 0.3:213 assessments across 200 games