Store, client, and game are different boundaries

1282. Lesson identity

Module

3.12 — Steam integration

Lesson

1 of the module

Academic type

Concept with assessed practice

Estimated time

30–40 minutes

Capability

Classify a Steam-related responsibility by system ownership and exposure requirements, then justify its placement and failure responsibilities.

1283. Learning objective

After this lesson, you can analyze a Steam-related responsibility in two dimensions:

1. assign its primary owning system boundary and, where necessary, a collaborating boundary; and
2. classify whether its data may be distributed or must remain secret and restricted.

You can also distinguish the game-owned player-facing response from the owner responsible for operational remediation.

1284. Why this matters

A feature may look unified to the player while spanning several systems. Product metadata is not runtime code, a client-provided capability is not a game rule, and a credential's secrecy does not tell you which system owns the process that uses it.

Mixing these questions can lead to configuration being placed in code, credentials being included in a distributable package, or the game being held responsible for repairing a platform configuration it cannot control. A two-dimensional classification gives you a clearer architecture before you select an API or ask AI to propose implementation details.

1285. Prior knowledge

You should be able to compare runtime environments and distinguish a development run from a packaged run, as practiced in 3.11 L2 — Compare runtime environments. This lesson extends that comparison by identifying who owns each responsibility and what may cross a distribution boundary.

1286. Dimension one: system ownership

Assign each responsibility to the system that has authority to perform or change it.

Choose one primary owner. If completing the responsibility requires another system, name it as a collaborating boundary and describe the handoff. Collaboration does not erase primary ownership.

For example, producing and uploading a distributable artifact may be owned by controlled build or release tooling, while choosing which uploaded artifact is associated with a store product may be store-side configuration. These are related responsibilities, not one indivisible setting.

1287. Dimension two: exposure and secret handling

After assigning ownership, classify the information used by the responsibility.

Secrecy is a handling constraint, not a single architectural location. A release credential can be owned by a controlled release process and separately marked secret, non-distributable, and restricted. A backend credential can be owned by a backend process under the same exposure classification.

Anything distributed to players should be treated as observable. Obscure names, configuration files, or compiled code do not turn a distributed value into a safe private credential.

1288. Handoffs and two kinds of failure responsibility

Use separate fields for two different decisions:

• Player-facing runtime response: Which part of the game decides what the player sees or can do when a capability is unavailable, denied, or returns an error?
• Operational remediation owner: Which team or controlled system investigates and corrects a store, release, service, or deployment problem?

The game normally owns its fallback behavior because it controls its interface and rules. That does not mean the game owns the underlying client service or can repair store configuration. For example, the game may disable a control and show a clear message, while release or platform operations investigate a configuration error.

1289. Boundary-map method

For each responsibility:

1. Describe the exact responsibility without naming an API.
2. Assign a primary owning boundary.
3. Name a collaborating boundary when the work genuinely spans systems.
4. Describe the handoff: metadata, artifact, availability signal, request, or result.
5. Define the player-facing runtime response. Write “not applicable” when no running-game behavior is involved.
6. Assign the operational remediation owner.
7. Classify exposure: distributable or observable, restricted but non-secret, or secret and non-distributable.
8. Justify the architecture: explain why the placement reduces a concrete risk or category error.

Compact form:

Responsibility → Primary owner → Collaborator → Handoff → Runtime response → Operational remediation → Exposure → Justification

1290. Worked example

Consider the request: “Show the game in the Steam store and let the player open the platform overlay from the pause menu.”

Notice that the credential is not itself an ownership boundary. Its owning process is identified first; secrecy is classified second.

1291. Common mistakes

Treating secrecy as a location

“Put it in secrets” does not identify which controlled process owns the credential. Name the release tool, backend, or other authorized environment responsible for using it, then state the handling constraint.

Assigning one failure owner for every failure

The game can own a safe player-facing fallback while another owner corrects store, release, or platform configuration. Record both responsibilities.

Combining artifact production and store association

Producing or uploading a compilation or package (build) may belong to controlled release tooling. Configuring which artifact is associated with the store product may belong to store configuration. State the exact responsibility and any collaboration instead of forcing both into one vague row.

Treating all Steam work as runtime code

A shared product label does not imply shared architectural ownership. Classify the responsibility before choosing an API or generating code.

1292. Guided practice

Prepare a five-row boundary map for these exact responsibilities:

1. Maintain the product description and screenshots shown in the store.
2. Present a pause-menu control that requests a client-provided capability.
3. Display a fallback when the platform client or requested capability is unavailable.
4. Use a private credential in a controlled server-side or release process.
5. Configure which previously produced distributable package is associated with the store product. Name the controlled release process as a collaborator if it produces or uploads the package.

For every row, provide the primary owner, collaborator or “none,” handoff, player-facing runtime response, operational remediation owner, exposure status, and a short architectural justification.

Then select one row that should not be implemented as game runtime code. Explain the category error or risk prevented by keeping it outside the game.

1293. Validation and evidence

Submit the five-row map through the attached practical assessment. It is evaluated for:

• correct primary ownership;
• precise collaborators and handoffs;
• separation of player-facing fallback from operational remediation;
• correct exposure and credential handling;
• an architectural justification tied to a specific risk.

The quiz checks the core distinctions. The practical assessment evaluates whether you can apply them to responsibilities with real handoffs and shared operational concerns.

1294. Key takeaways

• First assign the owning system; then classify exposure and secret-handling requirements.
• A secret is a handling classification, not a universal system boundary.
• The game owns its player-facing fallback, but it does not necessarily own operational remediation.
• Responsibilities spanning release tooling and store configuration need an exact primary owner and a named collaboration.
• Treat everything distributed in the client as observable.

1295. Next lesson

Continue to 3.12 L2 — Write an integration check without secrets. Carry forward both dimensions: system ownership and exposure controls.

1296. Knowledge check