Mission
- Measurable outcome: By the end, you can explain a system to a mixed audience, trace one request end to end, and identify at least three boundary assumptions and two missing signals.
- Prerequisites: Module 1, especially boundary and technical-judgment concepts.
- Work product: A system-context and request-trace worksheet.
- Time: 55–70 minutes.
Before you read: Predict → Commit → Connect
A diagram shows a mobile app, “backend,” and database. The team says the customer path is understood. Predict the first five questions you would ask. Commit to the boundary most likely to hide a launch risk. Connect this to Chapter 1.2: which of boundary, failure, evidence, or trade-off judgment are you applying?
Read from the outside in, then follow behavior
A TPM needs a correct-enough shared model, not an architect’s complete design. Start with the system context: users and operators, the system of interest, external systems, trust boundaries, and owners. Then trace a concrete request. A static inventory answers “what exists”; a trace answers “what must happen.”
For Meridian Pay, choose a specific scenario: an authenticated customer authorizes a purchase in Canada while the regional platform is receiving 10% of traffic. Avoid “payment goes through the backend.” Name the significant hops, state changes, synchronous responses, asynchronous follow-up, and evidence.
Accessible diagram label: The Meridian system context includes customer-facing clients, identity, payments, external banking, ledger, settlement, and the separate observability path used by operations.
Read context using seven prompts:
- Actor: Who initiates, receives, approves, or operates?
- Boundary: Where do ownership, trust, technology, geography, or vendor control change?
- Contract: What request, response, event, file, or physical interface crosses?
- State: Which record changes, and which system is authoritative?
- Time: Which steps are synchronous, eventual, scheduled, or manually queued?
- Failure: What can be slow, duplicated, missing, stale, unauthorized, or partly complete?
- Evidence: Which logs, traces, metrics, reconciliation, or user signals reveal reality?
Accessible diagram label: The request trace separates the customer-facing authorization path from the later reconciliation path and shows where durable acknowledgment is required.
A sequence diagram makes ordering assumptions visible. Does the customer receive approval before the ledger acknowledgment? What if the bank approves but the client times out and retries? What if settlement consumes an event twice? These are questions for engineering owners to answer and for the TPM to connect to requirements, testing, incident response, and launch gates.
Use progressive depth. First tell the 60-second story to a nontechnical executive. Then give the five-minute boundary and failure story to program stakeholders. Finally, ask engineering for the evidence behind the highest-consequence assumptions. Do not force every audience through every implementation detail.
Trace more than the digital happy path. Include the customer’s perceived response, operator intervention, asynchronous completion, and any reconciliation or notification that determines whether the journey is actually finished. A response code can report success while a downstream business obligation remains incomplete. That distinction keeps the model connected to the outcome rather than a convenient component boundary.
Validate the model through triangulation: architecture documentation, an engineer’s walkthrough, and production or test evidence. Diagrams drift. A trace identifier, dashboard, or controlled demonstration can reveal a queue, proxy, manual exception, or shadow database absent from the document.
Decision rights: Who owns what?
Architects and technical leads own the authoritative technical model and design decisions. Service teams own implementation and telemetry. Security owns or advises on trust boundaries according to policy. Operations or SRE owns operational procedures and signals where chartered. The TPM owns creating a shared cross-team view, finding contradictions, routing corrections, and connecting missing evidence to program risk.
The TPM should label uncertainty rather than redraw an unverified guess as fact. “Unknown owner” and “unconfirmed ordering” are legitimate diagram annotations.
I do
I trace Meridian’s retry scenario. The first model omits the merchant retry and assumes exactly one request. I ask for the idempotency contract, authoritative payment identifier, ledger write ordering, and observable duplicate rate. Engineering confirms the regional service creates a new identifier after one timeout path. I record a cross-team decision: preserve the original idempotency key through the edge, service, ledger, and reconciliation path; verify it with duplicate-injection tests.
We do
Helios Support receives a customer question, retrieves documents, asks a model to draft, may invoke a refund tool, and hands the answer to an agent. Together draw the request and approval path. Mark where customer authorization, document entitlement, model uncertainty, tool permission, and human approval must be visible.
Show the model answer
Model answer
The trace begins with authenticated customer and case context; retrieval must filter documents using current entitlements; the model receives only approved context; a policy layer constrains tool requests; a refund action requires authorization and, above a threshold, human approval; the ticket stores sources, draft, action, approver, and outcome. Signals include retrieval denials, unsupported-answer rate, tool rejection, approval latency, and audit completeness. Unknowns remain labeled until owners verify them.
Scoring rubric (0–4)
- 0: Draws a single “AI” box.
- 1: Lists components but no sequence, state, or boundaries.
- 2: Traces the happy path and names at least two boundaries.
- 3: Adds failure behavior, authoritative state, owners, and evidence.
- 4: Also distinguishes user-facing and asynchronous paths, marks uncertainty, and names a testable integration decision.
You do
Select one high-value and one failure scenario. Draw context once and a sequence for each scenario. Ask the seven prompts. Validate with one technical owner and one operator. Highlight every correction; those corrections are evidence of learning, not defects to hide.
Pause & Recall
Retrieve Module 1’s TPM center of gravity. Why does a shared request trace support that role? Name the seven reading prompts. Explain, without looking, why a context diagram and a sequence diagram answer different questions.
Production lens
Keep traces tied to real telemetry. During an incident, responders need identifiers that cross boundaries. During a migration, old and new paths must be distinguishable. During a privacy review, data movement and retention matter as much as request success.
Workplace artifact: system reading sheet
Scenario and actor:
System of interest / excluded systems:
User-visible success and failure:
Ordered hops and owners:
Contracts at each boundary:
Authoritative state and state changes:
Synchronous vs asynchronous steps:
Trust / geography / vendor boundaries:
Retry, timeout, duplicate, stale, and partial-failure behavior:
Trace identifiers and operational signals:
Unknowns and conflicting diagrams:
Evidence reviewed / expert validation:
Program decisions or risks created:Chapter compression
Read a system from context to behavior. Trace actors, boundaries, contracts, state, time, failure, and evidence. Validate documents against experts and observable behavior. The TPM owns shared understanding and consequence integration, not architectural authority.
Retrieval deck
- Q: What does a context diagram answer? A: Who and what surrounds the system, including external and trust boundaries.
- Q: What does a sequence diagram add? A: Ordering, interaction, response, and timing assumptions for a scenario.
- Q: Why mark authoritative state? A: Conflicting sources of truth create integration and recovery risk.
- Q: What is triangulation? A: Comparing documentation, expert explanation, and observed/test evidence.
- Q: What should a TPM do with an unverified fact? A: Label it as unknown or assumed and assign validation.
Spaced review
- Now: Name the seven system-reading prompts and apply one to Meridian.
- 1 day: Redraw the request trace from memory.
- 3 days: Inject a timeout, retry, or stale dependency and revise the trace.
- 7 days: Validate one boundary with an engineer and record your correction.
- 14 days: Compare the trace with telemetry or an operator walkthrough and log drift.