Follow One Request Through The System

An employee asks a company assistant, “What is our current hotel reimbursement limit?” A sentence eventually appears on the screen. Between the question and that sentence, several components have done different jobs. The interface, access checks, document collection, model service, and physical equipment are not interchangeable. A plausible answer can hide

a failure earlier in the chain. A slow answer can also have a cause far from the model's generation step. This lesson follows one request through the system. First, we'll trace the employee's question through the software stages. Then we'll connect those stages to the equipment and supporting resources underneath them. Finally, we'll diagnose a measured delay.

By the end, you should be able to locate a failure or a wait in the chain, identify what evidence is missing, and explain why improving one component may have only a small effect on the whole experience. The employee types into an interface: the part of the product they interact with. The interface sends a request to application software.

A request is a message asking another component to perform work. A response is the result or status returned. These messages may travel between processes within one computer or across a network. The visible conversation is one view of a larger exchange; it doesn't show every internal request or response. The application first establishes the user's identity and access.

Authentication asks who the user is, using an appropriate identity mechanism. Think of establishing which employee is making this request. The particular sign-in mechanism matters to the real system, but we don't need to implement it here. Our first distinction is the job it performs: establishing identity rather than deciding every document that person may read.

Authorization asks what that identified user is allowed to do or access. An employee may be allowed to read the general travel policy but not a restricted personnel file. A successful sign-in does not remove that boundary. As information moves between components, the system still needs to respect the access appropriate to this person and task.

Identity and permission answer different questions. Here's a checkpoint. An employee signs in successfully. Does that alone establish that they may retrieve every company document? No. Authentication and authorization are distinct. The sign-in establishes identity according to the system's mechanism.

Access still depends on what that user is permitted to retrieve or do. If a restricted document is returned, “the person was logged in” is not enough to establish that the disclosure was authorized. Next, the application needs useful material. Before a document can be found in a collection, that collection must contain material prepared for use.

Document ingestion is the work of bringing documents into that usable collection. If the latest travel policy was never included, a search cannot recover it from that collection merely because the employee asked clearly. This is a different failure from the model misreading a supplied policy. Retrieval is the process of

finding information relevant to a request. The application may search an approved collection for the travel policy, rather than ask the language model to invent the company's rules. Finding something relevant is not the same as finding the right version. A document can discuss hotel expenses and still be outdated, outside the employee's access,

or inapplicable to the question. For our worked illustration, imagine that the current approved policy states a hotel limit of one hundred and fifty dollars per night for the category being discussed. An earlier version states one hundred and twenty dollars. These are invented teaching figures. Selecting the old version could produce

an outdated answer even if the model accurately repeats the text it receives. Checking that the selected material is current addresses a different problem from checking whether any relevant document was found. Retrieved material becomes part of the context supplied to the model. Context is the use-time material the model can

consider for the current computation, within the system's limits. It isn't automatically the entire company archive. The application selects and supplies material. We therefore need to inspect what actually reached the model, not assume that every document available somewhere in the organization was available in this request. The model then processes its input. For a language model, a tokenizer

converts text into units called tokens. Tokens can correspond to words, parts of words, punctuation, or other units. One word is not necessarily one token, and particular boundaries depend on the tokenizer. This preparation step changes how the text is represented for computation. It does not, by itself, explain the answer

or prove that the right policy was supplied. The processor executes the model's computations using parameters and use-time state. Parameters are learned internal values, as we discussed earlier. Use-time state is information used as the current computation proceeds. Processing the employee's question and supplied policy is use of the model; the presence of new context does

not by itself establish a parameter update. The work still requires actual computations and working information on hardware. The output is converted into a form the application can display or process. Notice the return path. The model's output does not have to jump directly onto the employee's screen.

Application software can inspect it, reject it, request another step, or send it for review, according to the product's design. A returned model output is an intermediate result until we know how the surrounding application handles it. Validation is checking an answer against selected requirements. Does the cited source exist? Is the supplied number supported?

In our illustration, the current policy says one hundred and fifty dollars. An answer saying one hundred and eighty dollars needs investigation. Confirming that the cited document exists would not resolve that numerical mismatch. Source existence and support for the particular claim are different checks. The application may also check whether

the answer has the required structure and whether sensitive information is being exposed. Correct structure is useful, but it doesn't establish factual correctness. A neatly organized answer can still state the wrong hotel limit. Similarly, an answer that uses an accessible travel policy could expose other information it should not include.

We need to identify the actual checks performed rather than treat “validated” as a promise that every possible problem was caught. Validation can use deterministic checks, other tools, models, or human review. A deterministic check applies specified rules, such as checking for a required field. A rule that checks field presence

doesn't prove the field's value is supported. Another model can make mistakes, and a human reviewer needs appropriate evidence. Each method has limits. The useful question is which failure a check can detect, what it actually observed, and what remains untested. Finally, the interface displays the response, and the employee decides what to do.

If the answer is supported by the current applicable policy, it can help the employee act. If important facts remain uncertain, a fluent sentence doesn't remove that uncertainty. The displayed answer is the end of this chain, not evidence that authentication, access selection, retrieval, model computation, and validation all worked correctly. Logs and monitoring may record selected events along the way.

Records of admission, retrieval, generation, or errors can help troubleshooting, evaluation, and cost measurement. “Selected” matters: a system doesn't necessarily record everything we would like to know later. Those records also contain information. The design must consider what is retained and who can access it; an internal log is not automatically an appropriate place to expose

the employee's question or retrieved material to everyone. We can now locate several different explanations for a bad answer. The wrong user may have been identified. The wrong access may have been granted. The current policy may be missing from the collection, overlooked by retrieval, or replaced by an older version. The model may generate an unsupported number,

or a relevant check may fail to catch it. These are different investigations. Replacing the model would not automatically repair a missing document or an incorrect access decision. Now trace downward from the model computation. Execution needs a serving process: running software that accepts and handles model work. Admission is the decision to accept work

into that service under its capacity and rules; a request may be admitted, queued, or rejected. The process runs on hardware with memory for the information needed during computation. A model description alone does not supply an operating service with available capacity. Multiple machines communicate through networks. The service also depends on storage,

a facility, electrical power, cooling, and operations. Storage retains material. Networks move information between machines. Power enables the equipment to run, cooling removes heat, and operations keeps the service functioning. These are concrete dependencies of the request, even though the employee sees a small conversation window rather than routers,

memory, electrical connections, or cooling equipment. Those physical components have dependencies too. Semiconductors and equipment must be manufactured. Suppliers provide components and services. Facilities and equipment require labor, permits, capital, and contracts. Capital supplies financing; contracts establish relevant commercial arrangements.

We are locating these roles, not assuming a particular ownership structure or supplier relationship. The request's software path sits within a larger physical, organizational, and economic system. Trace upward again with a conditional example. If electrical capacity constrains the hardware that can be operated, fewer requests may be served simultaneously. For a given pattern of demand,

queues can grow and users can wait longer. This is a possible causal chain, not a diagnosis of every slow response. We need evidence that electrical capacity is actually the constraint in the system being examined. Longer waits can change the product experience. Some users may abandon the task. An application may limit work or

route some requests to a cheaper model. Those choices can change service quality, costs, pricing, and competitive position. We haven't established that a cheaper route provides an equivalent answer. The point is that a physical limitation can travel upward into product and commercial choices; it isn't confined to an equipment room.

Let's diagnose this hypothetical slow response. The total time is forty seconds: thirty seconds waiting in a queue, five seconds retrieving documents, and five seconds generating the answer. These are the distinct measured components given for this example. Thirty plus five plus five equals forty. We aren't assuming that every product has these timings, or that every queue sits at

the same point in a request path. Pause and calculate. If only generation becomes twice as fast, with the measured queue and retrieval times unchanged, what is the new total response time? Would the employee's wait be halved? Generation falls from five seconds to two and a half seconds.

The new total is thirty seconds of queueing, plus five seconds of retrieval, plus two and a half seconds of generation: thirty-seven and a half seconds. The saving is two and a half seconds, not twenty seconds. Making one part twice as fast does not make the whole request twice as fast.

The other measured parts still consume time. The queue is the largest measured component in this example. That tells us where much of this wait was observed. It does not yet explain why the queue exists. Before changing the system, investigate the queue's cause and how representative this measurement is. A faster generation step can be a real improvement while leaving most of the user's wait untouched.

Several causes are possible. Capacity may be insufficient for the work arriving. Scheduling may make a request wait while other work is handled. Burst demand can put many requests into the service together. A service policy may limit how quickly work is admitted. These possibilities call for different evidence and interventions. We should not label the thirty-second

queue an electrical problem, a processor problem, or a scheduling problem before investigating it. This also helps us distinguish stages before generation. A network can fail to carry a request. Admission can reject or hold it. Authentication or authorization can fail, and document preparation, retrieval, or freshness selection can go wrong. A failure before the model receives usable input

cannot be diagnosed simply by judging the fluency of an answer from a different successful request. Here's a checkpoint. Name four distinct places where the employee's request could fail before the model generates text. Be specific about the stage, rather than saying only “the AI failed.” Possible answers include authentication, authorization,

document ingestion, retrieval, freshness selection, network transport, and serving admission. Authentication concerns identity; authorization concerns access. Ingestion may omit needed material. Retrieval may miss it, while freshness selection may choose an old version. Network transport may fail to deliver a message, and serving admission may prevent work from starting.

Any four distinct stages from this set answer the question. Naming one makes the next investigation more precise. Keep the diagnosis connected to evidence. If the current policy is absent, investigate the collection. If an unauthorized document is supplied, inspect access enforcement. If most measured time is in a queue, investigate the queue before assuming that generation speed explains the wait.

This is how a request map becomes useful: it separates the observed problem from guesses about its cause and helps identify what to measure next. Return to the employee's hotel question. We traced a request from the interface into application software, through identity and access, selected material, model computation, and selected checks, then back to a displayed response.

We connected that work to serving software, hardware, networks, and physical and commercial dependencies. Each boundary has its own responsibilities. A visible answer and a good-looking diagram are not substitutes for evidence that those responsibilities were met. When examining a product, ask where the request went, what crossed each boundary, and which stage accounts for the observed result or delay.

You should now be able to explain why a wrong answer or a long wait can originate outside generation itself. Next, we'll examine how software components describe the operations and information they exchange, so the messages in this request path become easier to read.