Downloadable content crosses product design, store configuration, build delivery, entitlement checks, pricing, testing, support, and release operations. A useful control record maps the customer promise to the exact technical objects that deliver it and assigns an owner to every decision. Without that mapping, a store page can be live while the wrong package, depot, branch, or account entitlement remains configured.
Record product identity and promise
Start with the base game, DLC title, platform, region, supported language and operating system, release state, price owner, content owner, technical owner, and support owner. Describe exactly what the customer receives: files, maps, characters, quests, cosmetic access, soundtrack, or another feature. Separate paid content, free content, consumables, currency, and soundtrack products because platforms may deliver them differently.
Steamworks' DLC documentation says each DLC is identified by its own app ID. Content may be included with the base game and unlocked through ownership, or placed in a separate depot downloaded only for owners. The game must check whether the user owns the DLC. Put that delivery choice and entitlement method in the decision record.
Map every technical object
Maintain a table with DLC app ID, base-game app ID, depot IDs, package IDs, store package, retail or key package, developer package, branch, build ID, manifest, file group, install behavior, launch requirement, and in-game feature flag. For each object, list purpose, owner, environment, current value, last verified date, and change ticket.
Do not put signing keys, web API keys, account passwords, or unreleased commercial details in a broad document. Reference the approved secret vault item or restricted release record. Identify who may publish a build, edit packages, change pricing, issue keys, or move a branch to default. Access ability is not the same as approval authority.
Steamworks' testing documentation explains that internal developer accounts receive app and depot access through packages such as developer-compensation packages. It warns that adding a depot to a build does not automatically make it testable if the depot is missing from the package the test account owns. Document package membership and the test account's acquisition path as separate evidence.
Capture the decisions behind delivery
For each material choice, record the date, decision maker, alternatives, customer effect, download-size effect, compatibility risk, save-data risk, multiplayer impact, support effect, and rollback. Typical decisions include separate depot versus base files, automatic versus on-demand install, required base-game version, region or language availability, branch strategy, and what happens when ownership is removed or unavailable.
Define the customer-visible version and the technical build that implements it. Record whether a base-game update is required and how incompatible combinations fail. Steamworks notes that new DLC content downloads only when the user runs the newest game version. The release record should therefore tie the DLC build to compatible base builds instead of documenting each in isolation.
Assign testing and release ownership
Name who prepares the build, configures packages, verifies entitlement, tests clean installation, tests an update over the previous version, validates a non-owning account, checks languages and platforms, approves the store page, and authorizes release. Use controlled test accounts and documented test packages. Do not borrow customer credentials or infer the customer path from an administrator account that owns every package.
The test record should include owning and non-owning accounts, clean and existing installations, online and supported offline states, insufficient storage, interrupted download, reinstall, update, save compatibility, and account switching where supported. Each result needs device, operating system, branch, build, package, time, expected result, and observed result.
Document rollout, incidents, and support
Define the release order, maintenance window, monitoring period, success metrics, stop conditions, and rollback owner. Keep a package and depot diff for every release. Record player-facing known issues and support scripts without exposing internal credentials or unreleased content.
For an incident, capture affected app IDs, packages, builds, regions, accounts, symptoms, first bad release, containment, and customer remedy. Do not issue untracked replacement keys or alter production entitlements as an informal fix.
The documentation is complete when the promised content maps to app IDs, packages, depots, files, entitlement checks, and compatible builds; every change has an approver; positive and negative customer paths have evidence; secrets remain outside the record; and support and rollback owners know exactly what they control.
Sources
- Downloadable Content (DLC) — Valve Steamworks
- Testing on Steam — Valve Steamworks