AI Systems Foundations for Software Factory Architects
Explain only the AI concepts that change factory architecture, cost, security, evaluation, or operations decisions.
The chapter in one pass.
- Purpose: Explain only the AI concepts that change factory architecture, cost, security, evaluation, or operations decisions.
- Core rule: Models are replaceable runtime dependencies. Authority, state, verification, and recovery organize the factory.
- Design test: If a concept does not change selection, control, evidence, or failure handling, it belongs in a general AI course instead.
1. The decision problem
Architects need enough model literacy to bound context, select inference profiles, evaluate behavior, control data, and plan capacity. They do not need a history of every model architecture to design a governed delivery system. The useful question is not “Which model is smartest?” It is “Which qualified configuration meets this task's quality, safety, latency, availability, data, and cost contract?”
2. Core concepts and factory implications
| Concept | Practical meaning | Factory decision |
|---|---|---|
| Token | Unit processed and generated by a model | Context and output budgets, cost, truncation, stop conditions |
| Context window | Maximum active input/output sequence | Retrieval, compaction, history, governing-content allocation |
| Embedding | Vector representation useful for similarity | Retrieval index, privacy, refresh, model/version compatibility |
| Structured output | Response constrained to a machine-readable schema | Validation, retry, compatibility, tool-call safety |
| Tool use | Model proposes a typed capability call | Authorization, side effects, idempotency, receipts, containment |
| Inference | Runtime generation from a fixed model version | Capacity, latency, data path, caching, cost, availability |
| Sampling | Controls variation in generation | Reproducibility, repeated trials, uncertainty, task profile |
| Multimodal input | Text plus image, audio, video, or other media | Data classification, parsing, evaluation, bandwidth, accessibility |
| Adaptation | Fine-tuning or other model-specific behavior change | Registry, data governance, evaluation, rollout, rollback |
| Retrieval | Select external knowledge at run time | Freshness, permission, attribution, poisoning, revocation |
| Prompting | Configure instructions and examples at run time | Versioning, hierarchy, injection resistance, evaluation |
Training changes learned parameters. Adaptation specializes a model. Retrieval supplies current external information. Prompting supplies task instructions and examples. These mechanisms have different owners, risks, rollback paths, and evidence. Do not call every improvement “training.”
3. Inference economics and performance
End-to-end latency includes queue, context retrieval, prompt construction, time to first token, generation, tool calls, validation, and retries. Throughput depends on provider capacity, token volume, concurrency, batching, and model profile. Caching can reduce cost but is safe only when identity, tenant, purpose, policy, source, and configuration versions are in the key.
Track reserved and actual tokens, model calls, tool calls, elapsed time, queue time, evaluator cost, environment cost, and human attention per accepted outcome. A cheaper call that doubles retries may be the expensive system.
4. Model classes without architecture theater
General-purpose language models, code-specialized profiles, small local models, reasoning-oriented profiles, embedding models, rerankers, classifiers, and multimodal models are capability classes. Select by representative evaluation, data path, latency, cost, availability, tool and schema support, context behavior, and operational constraints. Model family names and internal architectures change faster than these decisions.
5. Registry, routing, and rollout
A model profile pins provider/model identifier, version or snapshot, region, input classes, task eligibility, system prompt, sampling, token limits, structured-output and tool settings, safety policy, fallback order, budgets, evaluation suite, and retirement policy. The router chooses only among qualified profiles. It records why, exact version, usage, fallback, and outcome.
Roll out model changes through offline evaluation, shadow comparison, bounded canary, outcome observation, and governed promotion. Preserve the prior profile and rollback conditions. A provider alias that changes behavior without an exact version requires drift monitoring and stronger admission controls.
6. Evaluation and uncertainty
Evaluate complete configurations: model, prompt, tools, context, harness, environment, policy, and evaluator. Use representative cases, deterministic checks, calibrated human or model graders, repeated trials for variable behavior, confidence intervals, adversarial cases, and outcome slices. A high average can hide catastrophic failures in a critical slice.
No single score establishes truth. Retain disagreements, uncertainty, and counterevidence. Promotion depends on predefined improvement and non-regression criteria, not a favorable anecdote.
7. Safety, security, privacy, and data governance
Model inputs and outputs may contain source code, credentials, personal data, regulated data, or proprietary context. Define allowed providers, regions, retention, training/data-use terms, redaction, encryption, and logging. External content can carry indirect instructions. Tool calls require policy outside the model. Embeddings and caches inherit source sensitivity. Bias and safety evaluation must match the real users, languages, repositories, and decisions affected.
8. Failure and fallback
| Failure | Correct response |
|---|---|
| Context limit | Recompile with explicit allocation; never silently drop governing content |
| Invalid structured output | Bounded schema repair or fail with original response retained |
| Provider unavailable | Approved equivalent fallback or explicit pause; record changed profile |
| Quality drift | Restrict profile, route to previous version, investigate by slice |
| Cost spike | Admission and budget control; do not bypass safety validation |
| Suspected data leakage | Contain, revoke credentials, preserve evidence, notify data/security owners |
| Nonconverging loop | Stop on attempt/improvement budget and escalate |
9. Tradeoffs and nonclaims
Larger models may improve difficult tasks but increase cost, latency, and data exposure. Local models can improve control but add serving, evaluation, and capacity work. Adaptation may improve repeated domain behavior but raises data and rollout obligations. Choose the simplest qualified mechanism. This primer does not teach model training mathematics or certify any model or provider.
10. Teach-back exercise
Given three synthetic tasks—exact repository lookup, ambiguous design review, and privileged deployment—choose deterministic logic, retrieval, model profile, tool authority, evaluation, and fallback. Defend why each model-related choice changes a factory control, cost, or evidence decision.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence