F6 (Archetypes) is where you start — not at the code. Before reading a single file, identify what category of system this is. A checkout service at an e-commerce company is almost certainly a request-response system with synchronous dependencies on inventory and payment, likely an event-driven archetype at the integration boundary. Knowing the archetype gives you the prior: what the system probably looks like, what failure modes it is naturally exposed to, what tradeoffs were almost certainly made.
F5 (Review Questions) gives you the structured probe. The seven questions — what does this do, who uses it, what are its dependencies, what does it guarantee, what does it not guarantee, what would break it, and what does failing look like — are not asked in any order. They are asked in this order because each answer primes the next. Answering “what does it guarantee” (question four) without first knowing “what are its dependencies” (question three) produces a false answer. The dependencies are what make the guarantee expensive to maintain.
F3 (Failure Modes) runs after F5. Once you understand the dependencies and guarantees, you can enumerate which failure modes the system is exposed to. A synchronous dependency on a payment provider is exposure to FM5 (Latency Amplification) when the provider is slow, and FM1 (SPOF) if the provider has no retry path. These are not guesses — they follow from the architecture.
F4 (Tradeoffs) names the decisions that produced the failure exposure. The synchronous dependency was a choice — AT10 (Synchronous vs Asynchronous). It bought simplicity. It cost resilience at the dependency boundary. Understanding the tradeoff does not mean the decision was wrong. It means you know what condition would make it wrong.