AI systems foundations
Understand models, requests, components, failure boundaries, and the operator's evidence-first role.
What you will practice
Map an AI application; Separate model and application; Trace a request lifecycle; Name the serving boundary.
Use the worked examples when needed, then test your understanding without them.
- 01Map an AI applicationAn AI application is a chain of components, not just a model. Trace the request from input validation through retrieval, inference and response checks; each hop can fail independently.Practice
- 02Separate model and applicationModel weights produce predictions; the application owns routing, authentication and presentation. A change to one layer does not automatically change the other.Practice
- 03Trace a request lifecycleA request lifecycle has separate waiting, retrieval, inference and validation stages. Compare durations within the same request rather than combining unrelated log lines.Practice
- 04Name the serving boundaryA serving boundary defines which process accepts inference requests and which dependencies it calls. A loopback listener is not evidence that a service is publicly reachable.Practice
- 05Read an inference contractAn inference contract specifies required fields, supported model identifiers and response shape. Validate the request before blaming a model for a rejected envelope.Practice
- 06Distinguish training and inferenceTraining updates learned parameters; inference uses a selected artifact to generate output. Generation settings can change inference behavior without changing the weights.Practice
- 07Identify deterministic componentsApplication arithmetic, validation and routing can be deterministic even when text generation is variable. Keep hard constraints in code instead of trusting generated prose to enforce them.Practice
- 08Recognize probabilistic outputA probabilistic system can return different valid wording for the same task. Compare task quality over repeated cases rather than demanding identical strings when exact wording is not a requirement.Practice
- 09Separate data and instructionsRetrieved documents are data, not trusted instructions. Keep the application policy separate and do not let a quoted document authorize tools or change the user task.Practice
- 10Locate an operational failureLocate the first boundary that failed. An HTTP request rejected by a gateway has not necessarily reached the model, so inspect the gateway error before changing generation parameters.Practice
- 11Read a system dependency mapDependencies form a directed map. A failed shared dependency can affect several healthy callers; confirm the dependency evidence instead of restarting every caller.Practice
- 12Define an operator signalAn operator signal names a quantity, unit and observation window. A bare latency number cannot support an incident claim until its aggregation and time range are clear.Practice
- 13Use evidence before actionSeparate observations from hypotheses. A correlation with a deployment is a useful lead, but logs, traces and a controlled comparison are needed before claiming cause.Practice
- 14Write a system baselineA reproducible baseline records artifact, configuration, dataset and environment versions together. Keeping only an average score makes later comparisons ambiguous.Practice
- 15Foundations review checkpointA sound system review connects one observed failure to a component, its evidence and a reversible next step. Do not turn a system map into an unsupported diagnosis.Practice