Cheatsheet: What happens in three seconds: the path your prompt takes
The seven steps
Section titled “The seven steps”| # | Step | What happens | What this means |
|---|---|---|---|
| 1 | Keys to chat box | Your text appears in the browser’s chat box. | The last moment when only your computer knows what you typed. |
| 2 | Browser to network | Browser wraps the text, hands it to the network. | Once it crosses onto the public internet, the trace of who-sent-what-when becomes observable (metadata, not contents). |
| 3 | The CDN (front door) | The vendor’s Content Delivery Network logs request metadata and forwards the contents inward. | First piece of vendor infrastructure that touches you. Metadata held according to the vendor’s log-retention policy. |
| 4 | Inside the model service | The model service receives the message as plaintext (the opposite of encrypted). | Vendor’s systems can read the message; the policy decides what they do with that capability. |
| 5 | The model thinks | The model generates a reply on the vendor’s hardware, one piece at a time. | Vendor’s systems can observe the reply as it is built. |
| 6 | The reply comes back | The reply travels the same chain in reverse, often streamed piece by piece. | Same systems, same observability, same logging. |
| 7 | The reply appears | The reply lands in your chat box. | Your side ends when you close the tab; the vendor’s side continues per their policy. |
About two to four seconds for a short message.
Two words to carry forward: Inputs and Outputs
Section titled “Two words to carry forward: Inputs and Outputs”Inputs = your messages (prompts). Outputs = the model’s replies.
One vendor’s vocabulary for your messages and the model’s replies. Other vendors use different words (prompts/responses, requests/outputs, or content as a single bucket) for the same two things. When that vendor’s policy says “we use your Inputs and Outputs to improve our Services,” the words map to the trip you just learned.
Path versus policy
Section titled “Path versus policy”| Layer | What it is | What it tells you |
|---|---|---|
| Path (structural) | What is structurally possible at each step. | The model service handles plaintext; that is the floor. |
| Policy (commitment) | What the vendor commits to doing with that capability. | The vendor’s policy promises what they do or do not do with the plaintext. |
Both layers exist. Both have to be read. Phase 4 teaches the policy reading; this lesson taught the path.
Three pitfalls to dodge
Section titled “Three pitfalls to dodge”| Pitfall | Reality |
|---|---|
| Confusing the path with the policy | The path is what is structurally possible. The policy is what the vendor commits to. Reading them as the same thing leads to either misplaced trust or misplaced fear. |
| Confusing encryption with secrecy | Encryption protects messages in transit. It does not erase metadata, hide the message from the recipient (the model service), or prevent storage after receipt. The padlock icon is a real, narrower protection than the word “encryption” suggests. |
| Skipping the CDN | A common mental model is “my computer sends to the model.” The actual path almost always has at least one intermediary, usually a CDN, which holds metadata about your interactions even when the vendor does not train on the contents. Knowing the CDN exists is enough; you do not need to know how it works. |
Vocabulary to carry forward
Section titled “Vocabulary to carry forward”- Round trip: the full journey of a single message-and-reply pair through the path.
- CDN (Content Delivery Network): the vendor’s geographically distributed front-door infrastructure.
- Request metadata: the wrapper around the contents: timestamp, region, message size, sometimes browser type.
- Model service: the vendor software that runs the model.
- Plaintext: the opposite of encrypted; readable text. Messages are plaintext inside the model service.
- Streaming: sending the reply back one piece at a time as the model generates it.
- Inputs / Outputs: vendor-policy terms for your messages / the model’s replies.
Where each piece gets resolved in the track
Section titled “Where each piece gets resolved in the track”| What | Where the track addresses it |
|---|---|
| Who sees what at each step | Lesson 2.2 (parties along the path) |
| When the model remembers, and when it doesn’t | Lesson 2.3 (persistence, context window) |
| What could go wrong at each step (threats) | Phase 3 (threat models in plain language) |
| Reading the vendor’s actual policy commitments against the path | Phase 4 (five-question vendor rubric) |
| Architectural alternatives that change the path itself | Phase 5 (local-first architecture) |