Chapter 2: The AI System Stack

1. Chapter Overview

People often describe a production AI system by its most visible technical choice: a model, prompt, retrieval system, or agent loop. Those choices matter, but none describes the product. The product begins with an outcome worth pursuing and ends with behavior delivered under real constraints.

The AI System Stack makes that chain of decisions visible. It defines nine layers:

1. Business problem
2. Engineering problem
3. Architecture
4. Evaluation
5. Harness
6. Context
7. Prompt
8. Foundation model
9. Infrastructure

That order is deliberate. The stack moves from the reason the system should exist to the substrate on which it runs. Along the way, each layer translates requirements for the layers below and receives evidence, limits, or feasibility feedback in return.

The stack is not a request path, deployment topology, delivery lifecycle, or team chart. One component may participate in several layers, and one layer may be implemented across several components. The stack is a causal reasoning model: it helps a team decide where responsibility belongs, which assumptions cross boundaries, how evidence is produced, and how local changes affect end-to-end behavior.

The primary engineering decision is to represent an AI product as a nine-layer system and make every layer's responsibility, output, owner, and adjacent-layer contract explicit.

Many apparent model failures are really failures of system alignment. Perhaps the business outcome was vague or the required engineering behavior could not be observed. The context may have omitted necessary facts, while the prompt carried policy that belonged in deterministic control. A team may even add evaluation after the architecture has made important behavior hard to assess. In each case, the infrastructure can work exactly as designed while the product fails.

This chapter defines the stack and its interaction rules. Later chapters own the detailed work inside the layers: product fit and risk, prompt design, context engineering, harness control, tool use, evaluation methodology, security and governance, deployment, operations, and reference architectures.

The main artifact is the AI System Stack Reference Model. It consumes Chapter 1's AI Systems Engineering Definition and Principle Set, then provides the shared layer and contract vocabulary used by the more specialized artifacts that follow.

2. Primary Engineering Problem

Teams need to decompose an AI system without losing the end-to-end behavior that gives the system value.

Without decomposition, responsibilities collect wherever implementation happens to be easiest. Product policy lands in prompt text, missing information is misdiagnosed as a model-selection problem, and control flow becomes natural-language instruction. Quality remains a matter of intuition because no layer owns the evidence required for acceptance. Such a system may work along a narrow demonstration path, yet remain difficult to explain, test, change, or operate.

Decomposition alone is not enough. A design can name every layer and still fail if the layers are treated as independent boxes. A context package is useful only relative to a task. A prompt is meaningful only relative to the context and model it governs. Model capability matters only relative to the behavior the harness exposes. Evaluation evidence matters only relative to an engineering requirement. Engineering behavior matters only if it contributes to a business outcome.

The core tension is separation versus coordination:

Separate concerns enough to make decisions inspectable and replaceable, while coordinating them strongly enough to produce one coherent product behavior.

The tension becomes visible as soon as a prototype turns into a shared production system. Specialists take ownership of different components, while model, prompt, retrieval, application, platform, and product changes proceed at different speeds. Local metrics become convenient substitutes for system quality. With no explicit layer contracts, several teams can make locally reasonable changes and still produce an end-to-end regression.

Consider a system that drafts a response from internal records. A poor response could be caused by several different failures:

• the business outcome did not specify whether speed or completeness mattered more
• the engineering problem did not define what a complete response must contain
• the architecture omitted an authoritative data source
• the evaluation layer measured fluency but not factual coverage
• the harness allowed generation to continue after required data was missing
• the context package contained stale or irrelevant records
• the prompt gave ambiguous instructions about missing information
• the model lacked a capability the upper layers assumed
• the infrastructure truncated input or exceeded a latency budget

Replacing the model might change the symptom, but it would not necessarily repair the failed contract.

The result should be traceable in both directions. Starting with a business requirement, reviewers can follow its constraints through engineering behavior, structure, evidence, controls, information, instructions, capability, and execution. Starting with a production symptom, operators can work upward from runtime facts to the affected behavior and business impact.

This traceability is not documentation for its own sake. It is what makes design review, diagnosis, ownership, and safe change possible.

3. Core Mental Model

The AI System Stack is a map of nine decision layers. Each layer answers a different engineering question and produces an output that constrains adjacent layers.

Design moves down the stack through translation: higher-layer intent becomes lower-layer requirements. It moves back up through evidence and feasibility, as lower-layer behavior reveals what the system can actually deliver and whether the original outcome is being achieved.

A stack view is decision-ready when three conditions hold:

• every material requirement has an owner and a downward trace through the affected layers
• every material probabilistic claim has supporting evidence, a bounded assumption, or an explicit unresolved risk
• contradictions at affected layer boundaries have been resolved or accepted by an accountable owner

The goal is not to fill nine boxes. The goal is to make the system's reasoning inspectable enough for the decision in front of the team.

Layer 1: Business Problem

The business problem answers:

What outcome matters, for whom, and under what business constraints?

The business problem gives the system a reason to exist. It identifies the affected stakeholders, the workflow or decision being improved, the value hypothesis, relevant constraints, and the accountable business owner.

A useful business problem is bounded. "Use AI to improve support" is a direction, not a problem statement. A bounded statement identifies the target outcome, the population or workflow affected, and the conditions under which the outcome matters. It does not prescribe a model or architecture.

This work produces an outcome statement that can be translated into engineering behavior. If engineers cannot make that translation, the business problem remains too ambiguous.

This layer does not decide whether AI is the appropriate solution or fully classify the risk. Chapter 3 owns AI suitability, product fit, blast radius, and human accountability. Within the stack, the business layer supplies the anchor against which system success is judged.

Layer 2: Engineering Problem

The engineering problem answers:

What observable system behavior would create the intended business outcome?

Here, the team converts aspiration into responsibility. It defines relevant inputs and outputs, behavioral expectations, system constraints, non-functional requirements, and conditions for success, failure, escalation, or non-action.

The distinction between the first two layers is essential. The business problem explains why the system should exist. The engineering problem defines what the system must do. If the two are collapsed, implementation teams receive an outcome such as "reduce handling time" and are left to infer whether the product should retrieve facts, draft a response, recommend an action, execute a change, or organize information.

The engineering problem should be expressed in observable terms. It may require the system to produce a grounded draft, abstain when required evidence is unavailable, preserve specific user constraints, or route a case when deterministic conditions are met. It should not be expressed as "use a stronger model" or "improve the prompt." Those are possible means, not the responsibility.

The resulting engineering problem statement has a defined behavioral boundary. Architecture must satisfy that contract, and evaluation must assess it.

Layer 3: Architecture

The architecture layer answers:

What components, boundaries, and flows will deliver the required behavior?

Architecture allocates responsibility. It defines component roles, data flows, control flows, action flows, state boundaries, external dependencies, and the placement of human and deterministic controls.

An architecture decision should explain where a responsibility lives and why. For a system that must refuse an irreversible action without approval, the architecture identifies where approval state is represented and enforced. It also shows how authoritative records enter the system boundary and, when behavior spans several turns or workflow steps, where durable state resides.

The architecture produces a system structure in which important responsibilities have deliberate homes. Nothing in the stack requires nine services or a particular application pattern.

This chapter treats architecture only as one layer in the reasoning model. Chapter 12 owns detailed reference architectures and pattern comparisons. Chapter 10 owns deployment and runtime architecture.

Layer 4: Evaluation

The evaluation layer answers:

What evidence will establish that the system behavior is acceptable?

Evaluation appears above the runtime interaction layers for a reason. Evidence requirements should shape the design, not merely inspect it after implementation. When the engineering problem names a behavior, the evaluation layer identifies what evidence would justify confidence in that behavior.

At this level, evaluation defines quality dimensions, acceptance evidence, and the relationship between expected and observed behavior. The immediate question is whether the system can produce the evidence needed for release and improvement. Datasets, rubrics, test techniques, sampling methods, and launch thresholds remain the province of Chapter 8.

The result is an evidence contract stating what the team must establish for each important behavioral responsibility. When an important behavior cannot be assessed, either the architecture is incomplete or the engineering problem is underspecified.

Evaluation is distinct from observability. Operational signals can supply inputs to evaluation, but the presence of logs and metrics does not decide whether behavior is acceptable. Chapter 11 develops the operational side of that relationship.

Layer 5: Harness

The harness layer answers:

What runtime controls turn model capability into bounded system behavior?

The harness is the deterministic and procedural control envelope around probabilistic behavior. It coordinates work, routes requests, validates intermediate and final outputs, manages state transitions, enforces boundaries, applies retries and fallbacks, and escalates when the system cannot proceed safely.

A model may propose an output or action, but the harness determines what happens next. It can require structured validation, withhold an action, select a different path, request missing information, or transfer responsibility to a human.

The harness produces a control envelope that makes permitted system behavior narrower and more predictable than the model's raw capability.

Chapter 6 owns the implementation of orchestration and control loops. Chapter 7 owns safe tool use and agentic action. In this chapter, the key distinction is responsibility: the harness controls runtime behavior; the model does not control itself because an instruction tells it to.

Layer 6: Context

The context layer answers:

What information should the model see for this interaction?

Context is the task-specific information package assembled for model use. It may include user input, selected records, retrieved material, prior interaction state, policy excerpts, tool results, or other evidence. The context layer decides which information is relevant, fresh enough, appropriately authorized, and trustworthy for the current task.

This layer distinguishes available information from supplied information. A system may have access to a large knowledge base, but only a bounded subset should become context for a particular interaction. It also distinguishes context from instructions: context provides information; the prompt defines how the model should behave with it.

What the layer supplies is an information package with explicit provenance, trust, authorization, and lifecycle assumptions. The harness and prompt need those assumptions in a visible form, not silently embedded in raw text.

Chapter 5 owns retrieval, ranking, compression, memory, token budgets, and permission-aware assembly. The stack-level concern is that context has a defined responsibility and contract rather than being treated as arbitrary text attached to a prompt.

Layer 7: Prompt

The prompt layer answers:

What instructions and output contract should govern the model interaction?

The prompt is the instruction interface between the system and the foundation model. It defines the task, relevant constraints, instruction hierarchy, expected response contract, and, where useful, examples that clarify intended behavior.

A production prompt is not a collection of persuasive phrases. It translates upstream control and information decisions into an interaction the selected model can interpret. It should have a defined purpose and version, and its claims should not exceed the model or harness capabilities supporting it.

The prompt becomes a versioned instruction interface. It can shape behavior, but it cannot reliably substitute for authorization, state management, validation, or enforcement. Those responsibilities belong elsewhere.

Chapter 4 owns prompt structure, refusal behavior, output contracts, examples, versioning, and prompt-specific testing. Here, the prompt is one layer whose boundaries prevent it from becoming a dumping ground for every missing system control.

Layer 8: Foundation Model

The foundation-model layer answers:

What capability profile do the upper layers require?

The model supplies probabilistic capability. Its relevant characteristics may include instruction following, reasoning, generation, classification, modality support, tool-use behavior, latency, cost, and limits under different inputs. The correct unit of discussion is the capability profile needed by the system, not the prestige or general benchmark position of a model.

The model layer also exposes uncertainty. Capability is conditional: it depends on the task, prompt, context, interaction pattern, and operating constraints. A model that performs strongly on one workload can be a poor fit for another. A model claim should therefore be treated as an assumption to validate in the complete system, not a product guarantee.

The model layer supplies a capability contract: what the upper layers rely on and which limitations they must contain. That contract keeps model selection subordinate to system requirements and turns substitution into a reviewable change rather than an act of faith.

Layer 9: Infrastructure

The infrastructure layer answers:

What execution substrate allows the complete system to run within its operational constraints?

Infrastructure provides compute, networking, storage, connectivity, configuration, secret handling, resource capacity, and availability foundations. It enables the architecture to execute and exposes limits that may propagate upward into product behavior.

For example, capacity limits may constrain concurrency, network placement may affect access to required sources, and storage characteristics may affect state or context availability. These are not merely platform details when they change latency, cost, reliability, or feasibility at higher layers.

Infrastructure supplies an execution environment capable of supporting the required behavior. It can deliver reliable execution without semantic correctness: a request may finish within its latency target and still produce the wrong outcome.

Chapter 10 owns deployment, configuration, versioning, routing, and rollback. Chapter 11 owns operational telemetry and incident practice. Within the stack, infrastructure is the substrate whose constraints must be connected back to system requirements.

The Interaction Model

The layers are ordered, but the system is not designed through a one-way waterfall.

Intent and constraints move downward:

• business intent becomes an engineering responsibility
• engineering behavior constrains architecture and evidence needs
• architecture allocates responsibility to controls and information interfaces
• harness, context, and prompt determine how model capability is used
• required capability constrains the execution substrate

Behavior, evidence, and feasibility move upward:

• infrastructure and model behavior produce runtime facts and constraints
• prompt, context, and harness interactions create bounded system behavior
• evaluation interprets observations against the engineering responsibility
• product results show whether the business outcome is actually improving

This bidirectional movement creates a design loop. A lower-layer constraint may require revising an upper-layer promise. A weak evidence path may require changing the architecture. An infrastructure constraint may alter model choice or the acceptable interaction pattern. The discipline lies in making those revisions explicit rather than allowing lower-layer convenience to redefine the product silently.

4. System Boundary

The stack covers the full chain of decisions from intended outcome to execution substrate. Its boundary also includes the translations between those decisions and the feedback that tests whether they remain valid.

Not every relevant entity sits inside one software boundary. Users, organizational policies, business processes, external systems, and human decision-makers may remain outside the technical implementation while constraining several layers. The design should record those relationships instead of pretending that application code contains all responsibility.

Several boundary distinctions prevent recurring design errors.

Architecture is not infrastructure

Architecture defines the system's components, responsibilities, state, and flows; infrastructure supplies the substrate on which those decisions execute. A service-and-network diagram may describe infrastructure without showing who owns validation, approval, or context assembly. Conversely, a sound logical architecture can still depend on capacity or connectivity that the available infrastructure cannot provide.

Evaluation is not observability

Evaluation defines the evidence needed to judge behavior, while observability reveals what occurred in operation. A trace can identify the prompt, context, model, and validation path used. On its own, it cannot establish that the response was correct or that the product outcome improved.

Harness is not prompt

A prompt instructs a model interaction; a harness controls the runtime path. Instructions can ask for a structured answer or refusal, but the harness decides whether to accept the answer, allow an action, or divert a failed interaction.

Context is not prompt

Context supplies task-relevant information, and a prompt explains how to use it. Combining both into undifferentiated text obscures provenance, authority, versioning, and change impact.

Model capability is not product responsibility

A model can generate, infer, classify, or propose. The product team remains responsible for how it frames, controls, assesses, exposes, and acts on that capability. Producing the visible output does not give the model business accountability.

The stack is therefore not:

• a linear request path
• a requirement to deploy nine services
• a delivery lifecycle or maturity ladder
• a team organization chart
• a substitute for detailed methods in later chapters

Although conceptual, this boundary is operationally useful because it contains every decision that must stay aligned for the product to deliver the intended behavior.

5. Design Principles

Principle 1: Start at the top and justify every translation

Start with the business outcome. Translate it into observable engineering behavior before selecting technical components, so every lower-layer choice can be explained by an upper-layer need.

This does not mean implementation constraints are ignored until the end. Feasibility flows upward throughout design. It means a current technical preference should not silently become the product requirement.

Principle 2: Give every layer an explicit contract

For each layer, record what it receives, decides, produces, assumes, and commits to its neighbors.

Use precise language. A guarantee is a deterministic property the layer enforces or a service property backed by an explicit reliability commitment. A behavioral claim is a probabilistic expectation supported by evidence under bounded conditions. A risk is a material condition the system does not yet support or contain.

Infrastructure and deterministic harness controls may provide guarantees within stated assumptions. Prompts, context packages, and foundation models usually provide claims that require evidence and containment. Calling a model behavior a guarantee does not make it one.

The contract need not be formal or exhaustive. It must be precise enough for a neighboring layer to rely on, for a reviewer to find the evidence behind a claim, and for a change owner to see which assumptions may no longer hold.

Principle 3: Separate capability, control, information, instructions, and evidence

Capability comes from the model; runtime control from the harness; information from context; instructions from the prompt; and evidence from evaluation. These responsibilities interact without becoming interchangeable.

When one layer compensates for another, the compensation should be deliberate and visible. Asking a prompt to format output can be appropriate; asking it to enforce an irreversible authorization boundary is not.

Principle 4: Design evaluation beside architecture

Define acceptance evidence while allocating responsibilities and flows. That evidence requirement often exposes missing state, absent provenance, ambiguous outputs, or behavior that the architecture cannot isolate.

The detailed evaluation strategy can mature with the system. The obligation to explain how important behavior will be assessed should exist from the beginning.

Principle 5: Treat every change as a cross-layer event

A local edit can invalidate a distant assumption. Replacing a model may change output structure, latency, cost, context tolerance, or tool behavior. Changing a context source can alter prompt assumptions and evaluation coverage, while an infrastructure limit can force truncation that changes product quality.

Review the contracts affected above and below the changed layer, not only the edited component.

Principle 6: Diagnose from the failed outcome inward

Begin with the observed business impact or engineering behavior, then inspect the layers that create, constrain, or detect it.

This avoids model blame as a default diagnosis. The model may be the cause, but the stack forces the team to test that conclusion against other plausible failures and containment responsibilities.

Principle 7: Optimize the complete system

Layer metrics matter only when connected to the engineering behavior and business outcome. Lower model latency may increase retries; a cheaper model may increase review load. More context can improve coverage while adding distraction and cost, and a stricter validator can hide errors at the price of higher abandonment.

An improvement at one layer is an end-to-end regression if it shifts failure or cost elsewhere without improving the target outcome.

6. Architecture Patterns

The following patterns describe how to reason with the stack. They are not application reference architectures.

Pattern 1: Top-down decomposition

Start with the business outcome, translate it into observable behavior, then allocate the responsibilities needed to deliver and assess it.

This pattern is useful when framing a new system or challenging a model-first proposal. Its main risk is ceremonial completeness: a team fills in nine boxes but leaves their contracts vague. The value comes from the translations, not from naming the layers.

Pattern 2: Bottom-up feasibility feedback

As the design develops, carry capability, latency, cost, capacity, and operational constraints upward. Those facts should revise the design or product promise through an explicit decision.

This pattern keeps the stack from becoming a one-way requirements exercise. It also prevents the opposite failure: allowing current model or infrastructure limits to redefine the business goal without an explicit product decision.

Pattern 3: Contract-based layer replacement

Define the behavior expected from a layer before changing its implementation behind that contract. A model, context source, validator, or infrastructure service may then be replaceable in principle.

Probabilistic systems make replacement less mechanical than a conventional interface swap. Even when schemas remain stable, behavioral distributions can change. The contract and the evidence supporting it must therefore be revalidated.

Pattern 4: Cross-layer change review

For any proposed change, trace upward to the behaviors and outcomes that may shift, then downward to dependencies and constraints that may no longer hold. Review each affected adjacent-layer contract in both directions.

This pattern is useful for changes described as "only" a prompt edit, model upgrade, new source, retry adjustment, or capacity optimization. The stack does not prescribe release mechanics; it exposes the scope of the decision that later release and evaluation practices must address.

7. Failure Modes

Failure mode 1: Starting at the model

The team chooses capability before agreeing on the outcome or required behavior. Product scope then grows around whatever the model demonstrates well.

The result may be technically impressive and commercially irrelevant. Stable acceptance criteria are also hard to establish when no one defined the intended responsibility.

Failure mode 2: Collapsing business and engineering problems

An aspirational outcome is passed directly to implementation teams. Different stakeholders infer different system responsibilities, and success criteria change as implementation proceeds.

A more detailed architecture cannot repair this gap. The team must first translate the outcome into observable behavior.

Failure mode 3: Turning one layer into a dumping ground

Prompts often accumulate missing policy, control flow, source data, formatting, validation, and exception handling because they are easy to edit. Similar overloading can occur in the harness or application layer.

The result is fragile behavior and unclear ownership. Because one surface represents several decisions, a change is hard to isolate and review.

Failure mode 4: Adding evaluation after design

The team assembles the system and only then asks how to prove it works. Important outputs lack provenance, behavioral states are not distinguishable, and failure paths cannot be reproduced or assessed.

Late evaluation does more than delay testing; it reveals that the architecture omitted evidence required for a responsible release decision.

Failure mode 5: Defaulting to model failure

An incorrect output is attributed to model capability before the engineering problem, context, prompt, harness, or infrastructure path is inspected.

The team then spends time and money replacing a component while preserving the defect. A new model may mask the symptom temporarily and make the contract gap harder to see.

Failure mode 6: Confusing infrastructure health with system reliability

Requests complete, services remain available, and error rates look normal. The user-visible behavior is still irrelevant, misleading, or incomplete.

Operational success is necessary. It is still not evidence of semantic correctness or business value.

Failure mode 7: Leaving layer contracts implicit

Components are individually documented, yet no record states what adjacent layers assume, commit, or claim. A valid local change breaks behavior elsewhere.

This happens especially often when ownership follows team boundaries: every team can show that its component met a local specification while the product failed.

Failure mode 8: Losing the composite system version

Prompts, context sources, harness logic, models, and infrastructure configurations evolve independently. The team cannot reconstruct which combination produced an observed result.

The stack does not define the deployment solution, but it exposes why the complete behavioral configuration must be identifiable.

Failure mode 9: Assigning ownership only by component

Specialists optimize their layers while no one owns the engineering behavior across them. Regressions become negotiations between teams rather than decisions against a shared outcome.

Layer ownership remains useful, but one person or group must also be accountable for the composite engineering result.

8. Tradeoffs

Separation versus coordination overhead

Explicit layers improve reasoning, ownership, and replaceability. Formalizing each distinction too heavily creates extra handoffs, duplicated artifacts, and slower iteration.

Use logical contracts without requiring every layer to become a separate service, repository, document, or team. The goal is clarity of decision, not organizational ceremony.

Abstraction versus implementation fidelity

A common stack lets reviewers compare unlike AI systems with a stable vocabulary. Taken too far, that abstraction conceals material runtime differences.

Add deployment, sequence, data-flow, or state views when the decision requires them. Keep those views traceable to the shared layer model so implementation detail does not erase end-to-end reasoning.

Replaceability versus integrated optimization

Stable contracts make components easier to change and expose hidden coupling. Tight integration, however, may improve latency, cost, or behavior for a specific workload.

Coupling is not automatically wrong. Accept it deliberately, document which assumptions it creates, and recognize the resulting change cost.

Early evidence design versus exploratory speed

Early acceptance evidence prevents untestable systems and exposes weak requirements. Premature precision can constrain exploration before the team understands the problem.

Match the strength of the evidence contract to the maturity and risk of the decision. Early exploration may begin with directional evidence, but increasing exposure or consequence demands stronger justification.

Layer autonomy versus end-to-end accountability

Specialized owners can improve individual layers quickly, but independent optimization can degrade the composite behavior.

Give layer owners freedom within explicit contracts while retaining one owner who can resolve tradeoffs against the complete engineering outcome.

Local efficiency versus system quality

A faster or cheaper model call may improve a local metric while increasing retries, human review, abandonment, or failure cost. Additional context may improve recall yet reduce relevance or break a latency constraint.

Evaluate efficiency where its consequences appear: at the level of system behavior and business outcome.

9. Production Checklist

Before approving an AI system design, confirm:

• The business problem names the outcome, affected stakeholder, constraints, and accountable owner.
• The engineering problem expresses observable system behavior rather than a preferred technology.
• A material business constraint can be traced through every affected lower layer.
• All nine layers are represented, including layers supplied by existing organizational capabilities.
• Every layer has a stated responsibility, expected output, and owner.
• Each layer records what it receives, decides, produces, assumes, and commits or claims.
• Deterministic guarantees are separated from evidence-backed behavioral claims.
• Each material probabilistic claim has supporting evidence, a bounded assumption, or an explicit unresolved risk.
• Adjacent-layer contracts are explicit enough to support change review and diagnosis.
• Architecture and evaluation were considered together.
• Capability, control, information, instructions, evidence, and execution are not conflated.
• Infrastructure constraints are connected to higher-layer system requirements.
• Human and deterministic responsibilities are visible where they affect behavior.
• A failed outcome can be traced to candidate contributing and containing layers.
• A layer change triggers review of affected assumptions above and below it.
• Local success measures connect to the engineering behavior and business outcome.
• The composite behavioral configuration can be identified for a reproduced result.
• One owner is accountable for the complete engineering outcome.
• The stack view is supported by, but not confused with, deployment and organizational views.

10. Design Review Questions

1. What business outcome anchors this system, and who owns it?
2. What observable engineering behavior is expected to create that outcome?
3. Which material requirement cannot be traced from business problem to the affected lower layers?
4. Where does each major responsibility live in the nine-layer stack?
5. What does each layer receive, decide, produce, assume, and commit or claim?
6. Which claims are deterministic guarantees, and which are probabilistic behavioral claims requiring evidence?
7. Where have two layers been collapsed into one implementation surface?
8. What behavior is delegated to a prompt but belongs in architecture, context, or the harness?
9. What evidence must the evaluation layer provide, and how did that need shape the architecture?
10. Which system qualities emerge from interactions rather than a single component?
11. If the model changed tomorrow, which contracts would require revalidation?
12. If context were stale, incomplete, unauthorized, or unavailable, where would the failure be contained?
13. Which infrastructure constraint propagates farthest upward into product behavior?
14. What local optimization could degrade the end-to-end result?
15. Who owns the behavior when every component is healthy but the product outcome is poor?

11. Main Artifact: AI System Stack Reference Model

Use this reference model to frame a design, locate a failure, or review a change. It names the minimum decision each layer must produce without prescribing how to implement it.

Artifact Control

• Reference-model identity and version:
• Source AI Systems Engineering Definition and Principle Set identity and version:
• System or product boundary to which this instance applies:
• Owner and reviewers:
• Effective date:
• Supersedes:
• Known omissions or unresolved cross-layer contradictions:

The artifact-control record keeps later references resolvable. A downstream artifact should cite this exact identity and version rather than referring vaguely to "the stack" or to Chapter 2.

Layer Reference

First Design Handoffs

The reference model is a source artifact, not a substitute for decisions owned by later chapters. Keep the first handbook handoffs traceable:

A receiving artifact may narrow or reject an upstream assumption. It must not silently broaden the product responsibility, autonomy, or accepted risk established upstream.

Layer Contract Record

For each layer, record:

• Receives: requirements, inputs, constraints, or evidence from adjacent layers
• Decides: the engineering judgment owned at this layer
• Produces: the output or contract supplied to another layer
• Assumes: conditions outside the layer that must remain true
• Commits or claims: deterministic guarantees, evidence-backed behavioral claims, or explicitly marked risks
• Evidence: what supports each material claim
• Owner: the person or group responsible for maintaining the decision

Use the following vocabulary consistently:

• Guarantee: deterministic behavior the layer enforces, or a service property backed by an explicit reliability commitment.
• Behavioral claim: a probabilistic expectation supported by evidence under bounded conditions.
• Assumption: a condition expected to hold but not enforced by the layer.
• Unresolved risk: a material dependency, behavior, or condition that is not yet supported, contained, or evidenced.

Keep the record short enough to review and precise enough to expose contradictions. If evidence does not support a guarantee, classify the statement as a behavioral claim, assumption, or unresolved risk instead of strengthening its wording.

Adjacent-Layer Boundary Map

Use this map to review the translations between neighboring layers.

Decision-Readiness Test

A stack view is ready to support a design, change, or launch decision when:

• every material requirement has an owner and a downward trace through affected layers
• every material probabilistic claim has evidence, a bounded assumption, or an explicit unresolved risk
• every affected adjacent-layer boundary has a stated contract
• contradictions between layer contracts are resolved or accepted by an accountable owner
• the team can identify the composite configuration associated with a reproduced result

Interaction Rules

1. Translate downward. Every lower-layer decision should be justified by a higher-layer need.
2. Validate upward. Lower-layer behavior becomes meaningful evidence only when interpreted against the engineering problem and business outcome.
3. Contract across boundaries. Record assumptions, guarantees, behavioral claims, and risks between adjacent layers.
4. Review changes in both directions. Inspect what the changed layer depends on and what depends on it.
5. Diagnose end to end. Begin with the failed outcome, identify the failed behavior, and then inspect the layers that create or contain it.

Change-Impact Lens

For any proposed layer change, record:

• the layer and decision being changed
• the higher-layer behavior or outcome that may shift
• the lower-layer capabilities or constraints that may be invalidated
• the adjacent-layer contracts requiring review
• the evidence needed to restore confidence
• the owner accountable for the composite result

This artifact gives teams a common reasoning surface. It does not replace the detailed specifications, plans, matrices, manifests, and runbooks introduced later.

12. Key Takeaways

• A production AI system spans nine decision layers from business problem to infrastructure.
• The stack is a causal reasoning model, not a runtime pipeline, deployment topology, lifecycle, or org chart.
• Intent and constraints move downward; behavior, evidence, and feasibility move upward.
• Reliability depends on contracts between layers as much as on the quality of any individual component.
• Deterministic guarantees and probabilistic behavioral claims must be distinguished.
• Capability, control, information, instructions, evidence, and execution substrate have distinct responsibilities.
• Evaluation must shape architecture early enough for important behavior to be assessed.
• Local changes should be reviewed as cross-layer events.
• The stack gives later chapters a shared vocabulary for deeper engineering decisions without losing the end-to-end system.