Trace one action through the architecture

977. Lesson identity

Module

3.1 — Runtime architecture

Lesson

Trace one action through the architecture

Academic type

Guided build

Schema type

Practical

Order

2

Estimated time

40–55 minutes, including practice

This lesson converts the ownership map from Lesson 1 of Module 3.1 into an execution trace. You will follow one player action across the runtime and record who creates, updates, communicates, and tears down each relevant object or responsibility.

978. Learning objective

After this lesson, you can trace one runtime action across its creation, update, communication, and teardown paths and identify at least one boundary whose owner or lifecycle responsibility is unclear.

979. Why this matters

A static architecture can look coherent while execution still crosses hidden or ambiguous boundaries. Tracing one action exposes where a decision is made, where state changes, and where communication depends on an assumed owner. This gives you a concrete way to evaluate an architecture instead of judging it by component names, folders, or code size.

It also exposes a common integration problem: a component appears to own a responsibility during normal execution, but no component owns its cleanup, cancellation, or replacement.

980. Prior knowledge

You should have completed Lesson 1 of Module 3.1, From game systems to runtime owners. You should be able to distinguish a game system from a runtime component and describe ownership as decision authority plus lifecycle responsibility. No particular engine, project, or codebase is required.

981. Core concept

An action is not a single function call. It is a path through runtime responsibilities.

For one action, inspect four connected paths:

1. Creation: Which owner creates the runtime object, subscription, request, or temporary state needed by the action?
2. Update: Which owner evaluates the action or advances the resulting state?
3. Communication: How does the decision or state change reach another component?
4. Teardown: Which owner removes, disables, unsubscribes, cancels, or otherwise retires the responsibility?

A trace is complete only when it accounts for all four paths. If something can be created or updated but no owner can explain how it ends, the architecture contains an unowned lifecycle boundary.

982. Mental model: the four-path action trace

Represent the trace as a chain rather than a list of disconnected components:

player action
    -> authoritative decision
    -> state update
    -> boundary communication
    -> presentation or dependent system
    -> teardown when the responsibility ends

For every arrow, name the sender, receiver, trigger, and owner. If the available evidence does not support one of those labels, mark it as unresolved instead of filling the gap with an assumption.

983. Concrete example

Consider a generic action: the player activates a temporary access gate.

The first three steps may appear functional, but the fourth reveals the architectural risk. If both the interaction controller and the access-session component can end the session, authority is split. If neither can end it, the lifecycle boundary is unowned. The trace does not prescribe a particular implementation; it makes the ownership decision visible.

984. Guided practice

Create a static execution trace for this action: the player requests temporary access permission. Do not implement code. Use a table, diagram, or plain-text document with these columns or equivalent labels:

Step | Trigger | Sender | Receiver | State or object affected | Owner | Lifecycle evidence | Open question

Step 1 — Define the action boundary

Write one sentence describing the action and its completion condition. Keep it narrow. For example: “The player requests access; the request completes when the runtime accepts or rejects it.” Do not trace an entire feature or play session.

Step 2 — Trace creation

Identify what must exist for the action to run. Record who creates it, what triggers creation, and whether creation is one-time, repeated, or conditional. If the action reuses an existing object, mark it as reused and name the owner that created it.

Step 3 — Trace update

Identify the owner that evaluates the action or changes its state after creation. Record whether the update is event-driven, frame-driven, timer-driven, or explicitly requested. Name the state that changes; “the system handles it” is not sufficient evidence.

Step 4 — Trace communication

Draw every boundary crossing. For each crossing, identify the sender, receiver, trigger, and communication mechanism. If the mechanism has not been decided, write undecided. Do not silently turn an unresolved boundary into a direct reference.

Step 5 — Trace teardown

Choose two ending conditions, such as successful completion and cancellation, unloading, or owner destruction. For each one, record who removes, disables, unsubscribes, cancels, or otherwise retires the temporary state, subscription, timer, object, or reference. If two components can perform the same cleanup decision, mark the authority conflict.

Step 6 — Diagnose one unowned boundary

Select one boundary that is ambiguous, unsupported, or divided between owners. Label it with one of these diagnoses:

• Missing owner: no component has explicit authority.
• Missing lifecycle: creation or update exists, but teardown is not assigned.
• Unclear communication contract: the expected behavior between sender and receiver is unspecified.
• Split authority: multiple components can make the same decision.

Write one ownership question that must be answered before implementation proceeds.

Decision checkpoint

Choose the owner for either the temporary state or its teardown. Explain why that owner has both decision authority and access to the necessary lifecycle events. If the evidence is insufficient, defer the decision explicitly and record what information is missing. Do not invent an owner merely to make the trace appear complete.

985. Practical assessment

Complete the linked Runtime action trace and ownership boundary project. Submit the trace, the diagnosed boundary, and the ownership decision or justified deferral. The project criteria distinguish a merely complete table from a trace supported by lifecycle evidence.

986. Validation evidence

Your trace must contain:

• One narrowly defined player action and a clear completion condition.
• At least one creation step, one update step, and one communication boundary.
• Two teardown conditions.
• A named sender, receiver, trigger, and owner for every resolved boundary.
• A visible distinction between confirmed ownership and open questions.
• One diagnosed unowned boundary using the provided categories.
• One ownership decision with a rationale based on authority and lifecycle access, or a justified deferral that names the missing evidence.

A strong trace allows another developer to determine, without guessing, what exists, who changes it, how the change crosses a boundary, and how the responsibility ends. It does not need to use a particular engine, class hierarchy, or communication pattern.

987. Key takeaways

• A runtime action is a lifecycle path, not just a call site.
• Creation, update, communication, and teardown must be traced separately.
• Every resolved boundary needs a sender, receiver, trigger, and owner.
• Missing teardown is an ownership problem, not merely a cleanup detail.
• Explicit uncertainty is more useful than an unsupported architectural assumption.

988. Handoff to Module 3.2

Preserve three items from your trace: the state that changes, its current owner, and the unresolved authority question. In Module 3.2, you will classify that state by scope and identify its authoritative writer. Do not assume that broad visibility or storage location determines ownership.

989. Knowledge check