Chapter 13: Case Studies

1. Chapter Overview

Production AI decisions make sense only in the conditions that made them difficult. System diagrams show components, evaluation reports measure behavior, and incident records capture what broke. A useful case study reconnects those views in time: what the team knew, which option it chose, what evidence challenged the choice, how operation changed the system, and which conclusions still hold.

The chapter's primary engineering decision is how to draw defensible lessons from an AI system without presenting one implementation as a universal recipe.

Four composite cases carry the analysis:

1. a support knowledge assistant that drafts grounded responses;
2. an internal engineering copilot that explains code and prepares changes;
3. a claims triage system whose proposed authority is materially narrowed;
4. a customer-success action system that prepares, but does not execute, external communication.

These cases are illustrative composites. The organizations, workloads, figures, timelines, and incidents combine recurring production conditions and have been altered to protect confidentiality. They remain internally consistent for analysis, but they are not empirical benchmarks. Each one separates information available at the decision point from facts learned later. That uncertainty belongs in the record; hindsight must not smooth it away.

To do that work, the chapter consumes decisions and artifacts established in Chapters 3 through 12. It does not re-teach product-fit assessment, prompting, retrieval, control-loop design, tool permissions, evaluation, security, release engineering, operations, or pattern selection. Its contribution is integration: showing what happens when those contracts constrain one another inside an operating model.

2. Primary Engineering Problem

The useful question is not, "Did the model work?" It is:

Given the responsibility, consequences, evidence, authority, and operating capacity available at the time, was this a defensible system decision—and what later evidence should reopen it?

Good model results can coexist with a failed product. An accurate classifier may overload the queue that inspects its exceptions. A grounded answer may cite policy that is authoritative but obsolete. Production volume can turn a real human approval step into a rubber stamp, while rollback can restore software without undoing external actions.

A credible analysis preserves causality across those boundaries and makes at least six things legible:

• the product responsibility the system was asked to assume;
• the credible alternatives, including a simpler or non-AI path;
• the evidence that enabled, blocked, or narrowed the decision;
• the end-to-end flow of information, authority, state, and effects;
• the initiating and latent conditions behind failure;
• the outcome, operating burden, residual risk, and reopening condition.

The analysis does not reward complexity. It asks whether the team chose the least powerful sufficient system and whether that choice's conditions of validity survived production.

3. Core Mental Model

Treat a case study as an evidence-backed decision trace.

Start with the baseline, not the architecture. Record what the team believed, who accepted the risk, and which event would invalidate the choice. Then follow a representative request or event through the system, including the point where a person or machine gains authority to create an effect. Compare what actually happened with both the original responsibility and the strongest credible alternative.

Three distinctions keep that trace honest.

Decision-time knowledge versus hindsight

Do not smuggle later facts into the original decision. A reasonable choice can fail when an explicit assumption proves false; an indefensible choice can succeed through luck. Decision quality and outcome quality are related, but they are not the same.

Component behavior versus system outcome

Model output is only one event in a larger path. Source freshness, control state, approval capacity, release identity, and downstream effects may dominate the result. Locate the contract that failed instead of ending the explanation with "the model was wrong."

Local observation versus transferable lesson

Every measured outcome belongs to a population, period, and operating model. A lesson travels only when another system shares the conditions that made the causal explanation plausible. Without those conditions, it remains a hypothesis to revalidate.

4. System Boundary

Chapter 13 owns end-to-end examples, architecture decisions, realistic tradeoffs, failure analysis, and lessons learned. It introduces no new architecture catalog, evaluation method, security framework, incident process, or tutorial implementation.

Earlier-chapter artifacts enter these cases as decision contracts. A Context Assembly Plan may name an authoritative source, a Tool Permission Matrix may forbid external communication, or an Evaluation Plan may lack evidence for a consequential slice. The case shows how each fact changes scope or operation; it does not explain how to construct the artifact.

Each case declares an authority boundary. Drafting is not sending. Prioritizing is not adjudicating. Preparing a patch is not merging it. Creating an internal task is not making a customer commitment. These are product responsibilities with different blast radii, not wording choices.

Illustrative figures make workload, capacity, and tradeoffs concrete, but they are not reusable thresholds. Each system needs thresholds grounded in its own consequence model and evidence.

5. Design Principles

Principle 1: Context precedes architecture

Begin with the baseline workflow, affected parties, consequence, constraints, unknowns, non-goals, and minimum useful outcome. Naming the pattern first makes the architecture look inevitable.

Principle 2: Alternatives must be credible

Use ordinary search, rules, workflow redesign, manual operation, or a narrower AI responsibility as alternatives when they are genuine contenders. A weak straw alternative teaches nothing.

Principle 3: Evidence must change a decision

Evidence earns its place by launching, blocking, narrowing, rolling back, or reopening scope. A metric with no connected decision is description, not engineering control.

Principle 4: Human controls are operating commitments

Human review is an operating commitment: a role with authority, evidence, skill, a service expectation, capacity, an escalation route, and safe overload behavior. If the organization cannot sustain that commitment, the control does not exist in practice.

Principle 5: Failure analysis crosses layers

Trace failure from the expected invariant through the initiating event, latent conditions, propagation, consequence, detection, containment, recovery proof, durable correction, and residual risk. An undesirable output is not a complete explanation.

Principle 6: Transfer conditions are part of the lesson

A credible lesson names what was local, what probably caused it, what changed, which conditions support transfer, what must not be copied, and which event requires revalidation.

6. Architecture Patterns

Chapter 12 defines the reference patterns used below. This section examines what happened when teams applied those patterns under concrete constraints.

Case 1: A support knowledge assistant meets an authoritative-source conflict

Decision context

Provenance and horizon: Illustrative composite covering a six-month design and operating period. Organization, product, and source names have been removed; workload, outcomes, timelines, and incident figures are constructed. The case assumes a business-to-business software provider with contractual response targets.

The support organization handled about 18,000 inquiries per month. Agents searched a public documentation site, an internal operations manual, and policy notices maintained by three product groups. Median research time for a nontrivial case was eleven minutes. Seven percent of resolved cases reopened within fourteen days, commonly because an answer omitted a policy exception or relied on superseded guidance.

The team proposed preparing customer-response drafts with supporting passages. Customers, support agents, policy owners, and the service owner accountable for response quality all carried some consequence. An incorrect configuration answer was usually reversible; an incorrect billing, refund, access, or data-retention answer could create a contractual or trust failure.

Send authority, case resolution, policy waiver, and conflict adjudication stayed outside the system. Success meant cutting research time for standard product questions by 25 percent without increasing unsupported or outdated claims. The team still lacked reliable estimates for source conflicts, meaningful review time, and the chance that agents would treat citations as decoration rather than evidence.

Options and decisions

Two material decisions each required three credible options.

The Context Assembly Plan made public documentation authoritative for product behavior and the operations manual authoritative for support procedure. Policy notices could override both, although their effective-date metadata was inconsistent. This source policy pulled against the response-time objective: the newest authority was also the least reliably indexed.

That tension shaped four inherited contracts. The Harness Control-Loop Diagram required a current-source check before drafting and a conflict state that returned passages without synthesizing a recommendation. The Production Prompt Specification required claim-level support or abstention. The AI Fit and Risk Assessment Worksheet excluded billing, refunds, access restoration, and data retention from the initial population. Because citation meaning depended on compatibility, the AI Release Manifest bound the prompt, source-policy configuration, retrieval index, and model route into one effective release.

Decision trace

1. Initial hypothesis: A cited drafting assistant could remove repetitive research while leaving customer communication with the agent.
2. Prototype evidence: Ranked passages reduced median research time by 18 percent; cited drafts reduced it by 37 percent, but performance varied sharply by case type.
3. Scope decision: The product owner approved a pilot for standard product questions and excluded consequential policy categories.
4. Control evidence: At an arrival rate of 60 pilot drafts per hour, agents spent a median of 2.6 minutes reviewing. After the third hour of a shift, unsupported-claim detection fell in the review study. The team capped each agent's assisted queue and preserved ordinary search as the overload mode.
5. Staged launch: Ten percent of eligible cases entered the assistant path. Agents saw the cited passages, source dates, and a visible abstention reason. They could edit, discard, or send; the system could perform none of those actions.
6. Production incident: A source-lifecycle defect generated obsolete refund-language drafts in a category that should have been excluded.
7. Containment and correction: The team disabled all policy-sensitive drafting, rebuilt the effective release, strengthened source validity as a pre-draft invariant, and added direct monitoring of exclusion leakage.
8. Current state: Standard product drafting resumed at 35 percent exposure. Consequential policy categories remained search-only.

Representative system trace

A support agent opens an eligible case. The system checks the customer's product entitlement and case category, retrieves passages permitted for that agent, validates source identity and effective date, and either produces a structured draft with claim-level citations or enters an abstention state. The agent receives the customer message, passages, source metadata, and draft in one view. Only the agent can edit and send. The sent response retains the effective release identity and cited-source identities so a later correction can locate affected cases.

A trained support agent held customer-communication authority. The operating plan allowed three minutes per review and at most twelve assisted cases in an agent's queue. Review meant inspecting support for material claims, not approving polished prose. Unreviewed drafts expired at the end of the shift and could never send on timeout. A full queue or unavailable source validity returned the agent to ordinary search and manual composition. This control was meant to interrupt the path from plausible unsupported text to a customer-visible statement.

Evidence ledger

Failure and change analysis

The initiating event was publication of a refund-policy notice whose effective date was present in the source document but missing from the indexing event. Latent conditions made the event consequential: the old notice remained highly ranked; category classification used the customer's wording rather than the agent-selected resolution category; the exclusion check occurred before retrieval; and the output contract permitted a draft when one apparently authoritative source was present. Reviewers saw a polished draft and a valid-looking citation. Under heavy queue load, several treated the citation as proof of currency.

The violated invariant was: no policy-sensitive draft may be produced unless category eligibility and source currency are both validated against the material actually used. The old design enforced the two checks at different points against different representations.

Over nine hours, 43 obsolete drafts were generated. Eleven were sent; three customers required correction. A customer reply was the first reliable signal because monitoring counted citation presence but not source validity or exclusion leakage. The team disabled policy-sensitive drafting, identified affected responses from release and source identities, notified case owners, and required correction where appropriate. Recovery was verified by replaying the affected cohort and confirming that each case entered abstention or manual search.

The durable change moved eligibility and source-validity checks after retrieval, made effective date mandatory for policy sources, added an exclusion-leakage signal, and separated citation presence from citation validity. Policy owners also received an explicit publication contract. Residual risk remains when authoritative content is substantively wrong rather than stale; the policy operations owner accepts that risk for standard-product scope and requires immediate suspension when a policy correction is issued.

Outcome and transfer

At the current 35 percent exposure, eligible cases show a 27 percent median handling-time reduction and no observed increase in reopening rate over eight weeks. Agents discard 9 percent of drafts and encounter abstention in 14 percent of eligible requests. The controls add policy-on-call work and source-lifecycle ownership that ordinary search did not require. Refund, billing, access, and retention responses remain search-only.

Within this bounded, stable knowledge population, cited drafting reduced handling time. Integration into the agent's existing evidence view—not fluent generation alone—most plausibly removed the research work while preserving send authority. The lesson travels only to settings where sources have enforceable validity, reviewers can inspect support under real load, and failed checks lead to a usable manual path. Neither the exposure level, queue cap, nor source hierarchy transfers. Any change in content ownership, case mix, or reviewer capacity reopens the decision.

Case 2: An engineering copilot is narrowed by repository change and user authority

Decision context

Provenance and horizon: Illustrative composite covering nine months. Company, repository, and migration identities have been removed; figures and outcomes represent a fictional engineering organization of 430 developers across 70 actively maintained repositories.

Engineers spent substantial time finding service ownership, understanding unfamiliar code, and applying repetitive internal API migrations. New engineers reported a median of six working days before completing a first cross-service change. Repository search was strong for exact symbols but weak for questions that crossed code, design records, and operational guidance.

The initial responsibility was explaining repository behavior; preparing a reviewable patch in a user-selected workspace came later. Approval, merge, branch-protection bypass, production-configuration change, and access to repositories outside the user's permissions all remained prohibited. The user stayed the author of every submitted change.

The smallest useful outcome was faster code comprehension with no increase in escaped defects. Open questions concerned repository drift, the chance that prepared patches would shift work onto reviewers, and whether permission-preserving context could answer cross-repository questions with enough evidence.

Options and decisions

Architecture review selected a copilot with repository-scoped context and a prepared-change modifier. Permission-aware context soon conflicted with the desired cross-repository explanations: the Context Assembly Plan prohibited inaccessible upstream code even when public interface documents referred to it. A broad cached index might have filled those gaps, but it violated the AI Threat Model decision. The system instead disclosed the missing authority and asked the user to request access or narrow the question.

The Tool Permission Matrix allowed read operations within user authority and writes only to the user's isolated workspace. The Production Prompt Specification separated explanation, cited evidence, proposed diff, and unresolved assumptions. The release identity included repository revision because a correct answer against yesterday's tree could be wrong today.

Decision trace

1. Baseline: Repository and documentation search remained available as the non-AI path.
2. Explanation pilot: A six-week pilot showed meaningful time savings on ownership and code-path questions but poor performance on undocumented cross-service behavior.
3. Scope correction: The team added explicit missing-context states rather than broadening hidden access.
4. Prepared-change proposal: Two repetitive API migrations had machine-readable constraints, owned examples, and deterministic test suites. They became the only write-enabled scenarios.
5. Evaluation decision: Patch preparation met the bounded claim for single-repository migrations but failed cross-repository and build-system slices. Those populations stayed explanation-only.
6. Near miss: A prepared patch used a deprecated migration example that remained in an archived design record.
7. Durable change: Example authority moved to the migration owner, revision compatibility became an invariant, and archived records could inform explanation but not patch generation.
8. Current state: The copilot explains broadly within user permissions and prepares changes for two bounded migrations. Engineers create and own any pull request.

Representative system trace and human control

The engineer selects a repository and question. The system records the repository revision and user identity, retrieves permitted code and documents, identifies missing sources, and returns an explanation with citations. For an eligible migration, the engineer explicitly requests a prepared change. The harness validates migration type and repository revision, writes only to an isolated workspace, runs the required tests, and presents the diff, assumptions, and test evidence. The engineer may discard, modify, or submit it through the ordinary review path.

The human control is not a generic approval click. The engineer has authorship responsibility and repository knowledge; the code reviewer has independent merge authority. Prepared changes are limited to a size that can be meaningfully inspected. They enter the existing team review queue with no automatic approval or promised turnaround; if a qualified reviewer is unavailable, the change remains unmerged. If tests are unavailable, the revision changes during preparation, or the diff crosses an ownership boundary, the system returns an explanation and no patch. There is no timeout that converts missing review into acceptance.

Evidence ledger

Failure and change analysis

The initiating condition was retrieval of an archived design record containing a once-valid migration sequence. Latent conditions included a high textual match, no authority distinction between current examples and historical rationale, and a test suite that checked compilation but not the new runtime contract. The expected invariant was that a prepared migration must be compatible with both the selected repository revision and the migration owner's current contract.

The system produced a compiling patch. The author noticed a deprecated initialization call during review and discarded it before submission. No repository was changed, but the near miss contradicted the belief that passing tests plus a current repository revision was sufficient. The team suspended patch preparation for that migration, replayed the evaluation set with archived records, and restored service only after those cases correctly produced explanation-only output.

The durable correction separated historical evidence from action-authorizing evidence, added the migration specification identity to the effective release, and required a contract test owned outside the copilot team. Residual risk remains when an owner publishes an incomplete migration contract. The migration owner accepts that risk only for the two named migrations and can withdraw patch authority independently of the explanation service.

Outcome and transfer

After nine months, active users completed measured code-understanding tasks faster and the two eligible migrations required fewer author hours. The organization saw no detected increase in escaped defects for the bounded population, but review-time savings were smaller than authoring savings because reviewers still reconstructed intent. About half of engineers used the explanation feature monthly; fewer than a quarter used patch preparation. The system introduced index-permission audits, migration-specification ownership, and evaluation maintenance costs.

Although explanations and prepared changes shared context, they required different evidence and authority. Isolated workspaces, explicit eligibility, and ordinary code ownership most plausibly contained error without pretending that the copilot owned the change. That lesson applies where repository permissions are enforceable, revision identity is durable, review remains strong, and transformations stay bounded. It does not support autonomous pull-request creation, merging, or broad changes. Permission changes, weaker test ownership, or expansion beyond the two named migrations reopen the decision.

Case 3: Claims triage evidence supports prioritization but blocks automated routing

Decision context

Provenance and horizon: Illustrative composite covering a seven-month discovery, shadow, and limited-production period. Organization, product, population, and obligation details have been transformed; all figures and outcomes are fictional. Ground truth in this workflow arrives late and can be disputed.

A claims operation received roughly 62,000 submissions per month across property, travel, and income-protection products. Intake staff checked completeness, identified urgent handling obligations, and routed claims to specialized teams. Median time to first qualified review was 19 hours. A small number of urgent claims waited longer because urgency evidence appeared in attachments rather than structured fields.

The original proposal was to classify and route every claim automatically. The consequence was asymmetric: a routine claim sent to an urgent queue consumed scarce capacity, while an urgent claim sent to a routine queue could delay support or breach an obligation. Final claim outcomes were unavailable for weeks and did not always establish whether the initial route had been appropriate.

Claimants, intake specialists, specialist teams, compliance owners, and operations leaders all stood inside the consequence boundary. The system could not determine eligibility, approve or deny a claim, calculate payment, communicate an outcome, or change a legal deadline. Its smallest useful contribution was earlier visibility of potentially urgent claims without degrading access for underrepresented or attachment-heavy populations.

Label reliability, rare-category coverage, attachment extraction, review capacity, and anchoring from the priority score were all unresolved.

Options and decisions

The AI Fit and Risk Assessment Worksheet exposed responsibility as the decisive issue. Automated routing would commit a claim to a consequential operational path; queue prioritization changed order while leaving route selection and deadline ownership with intake specialists. The team accepted the narrower responsibility.

The Evaluation Plan then collided with the operating model. Offline evidence suggested that a wide review band would catch more urgent cases, but peak staffing required 41 reviewers. Only 24 trained intake specialists were available without draining the ordinary claims queue. Model performance could not set the threshold by itself; combined evidence and the safe overload mode determined launch scope and queue capacity.

Decision trace

1. Initial proposal: Automatically route all claims to reduce first-review time.
2. Label audit: Historical route labels reflected staffing and local practice rather than consistently adjudicated correctness. The team rejected them as the sole source of ground truth.
3. Shadow evaluation: Aggregate results appeared strong, but recall for attachment-heavy urgent claims and two language populations missed the consequence-weighted threshold.
4. Authority decision: Automated routing was not approved. Prediction could surface standard property claims to intake specialists, who retained route authority.
5. Capacity test: Reviewers received the full claim, extracted urgency evidence, model rationale, and deadline data. At peak volume, meaningful review required more capacity than available.
6. Scope reduction: The product owner limited the queue and specified first-in-first-out processing as the overload fallback; no low-priority item could fall outside statutory deadline tracking.
7. Shadow near miss: A cluster of urgent claims with handwritten attachments received low priority because extraction produced empty text.
8. Current state: Standard property priority assistance is live. Automated routing, travel, income-protection, and unreadable-attachment populations remain unapproved.

Representative system trace and human control

An incoming standard property claim receives a durable claim identity and deadline record before any model processing. Structured fields and permitted attachment text are evaluated for priority assistance. Missing or low-confidence extraction creates an explicit unreadable state; it does not become evidence of low urgency. The system may place an eligible claim in a capped priority-review queue. An intake specialist sees the original submission, extraction status, highlighted evidence, deadline, and system rationale, then selects the route. The ordinary queue continues under deterministic deadline controls.

The specialist has route authority and must be trained for the product. The operating target allows four minutes per assisted review. The queue is capped to staffed capacity, and items age into ordinary deadline-based handling rather than wait indefinitely. Disagreements are recorded and sampled by an independent quality team. Under overload, prioritization stops; deadline tracking and manual intake continue. This human control is intended to break the path from uncertain priority evidence to an inappropriate route, not to validate claim eligibility.

Evidence ledger

Failure and change analysis

In shadow mode, the initiating condition was a scanning change that reduced handwriting extraction quality. Latent conditions included an evaluation corpus dominated by typed attachments, an early implementation that represented empty extraction as an empty document rather than an extraction failure, and a priority feature that treated absent urgency terms as negative evidence. The violated invariant was: unreadable evidence must never lower a claim's priority.

Thirty-seven urgent claims in the shadow cohort would have entered the ordinary queue without a priority flag. No claimant was affected because the system had no routing authority and the shadow outputs did not change order. The first reliable signal was a slice-level comparison performed after specialist adjudication; aggregate priority precision improved during the same period and would not have exposed the failure.

The team paused the planned live date, introduced an explicit unreadable state, routed extraction failures to manual inspection within the capped queue, and added attachment-quality coverage to release evidence. Replay against the affected cohort verified that the claims no longer received a negative priority signal. Residual risk remains for legible attachments whose meaning is domain-specific or indirect. The claims operations head owns that risk within standard property scope; specialist routing and deadline controls remain mandatory.

Outcome and transfer

The success here is narrower responsibility, not automation of the original proposal. Automated routing was rejected. Priority assistance brought surfaced urgent standard-property claims to qualified review sooner, but overall claim-cycle time did not improve during the observed period. The system also added specialist sampling, delayed-label adjudication, and attachment-quality operations. Travel and income-protection products remained manual. The team would retire the priority path if its capacity burden displaced more urgent work than it surfaced.

An apparently strong classifier did not justify route authority across asymmetric, weakly labeled populations. Delayed ground truth, extraction failure, and finite review capacity—not the aggregate score—set the safe responsibility. This lesson applies only where ordering is reversible, authoritative deadlines remain independent, and people retain genuine routing capacity. Prioritization is not harmless, and evidence for one population does not silently cover another. A change in product mix, extraction pipeline, staffing, or obligation rules reopens the decision.

Case 4: A customer-success action system fails safely at the effect boundary

Decision context

Provenance and horizon: Illustrative composite covering five months of staged production. Organization, account, source-system, and incident details have been transformed; workloads, timelines, outcomes, and incident figures are constructed. The system responds asynchronously to account events and holds durable state.

Customer-success managers monitored product usage, renewal dates, support escalations, and implementation milestones for 4,800 accounts. Relevant signals were spread across several systems. Managers often created follow-up tasks days after an event, and 16 percent of high-priority accounts had no recorded response within the internal target.

The bounded proposal allowed the system to interpret eligible signals, prepare an internal task, and draft a possible customer message. It could not send messages, update contract terms, promise remediation, alter account health, or schedule meetings. The account owner retained all external communication and commitments.

Earlier, more consistent follow-up for high-priority accounts was enough to justify the work only if duplicate contact and inappropriate escalation did not increase. Event duplication, cancellation after account-state change, approver capacity, and the usefulness of prepared actions remained unknown.

Options and decisions

The event-driven workflow agent inherited two binding contracts. The Tool Permission Matrix allowed account-system reads and internal-task writes while denying external communication. The Harness Control-Loop Diagram required proposed, awaiting_owner, cancelled, expired, and completed states. Yet the initial release deduplicated on a connector event identifier, leaving a seam between transport identity and business identity.

The account owner—not a pooled reviewer—held approval authority. Owners received the source events, current account state, proposed task, and draft, then could approve the internal task, edit it, discard it, or mark the signal obsolete. The plan budgeted 90 seconds for review, with eight operations specialists covering unassigned accounts. Once the approval queue exceeded one business day, new preparation paused while deterministic renewal reminders continued.

Decision trace

1. Baseline: Deterministic renewal reminders remained the reliable fallback, but they did not connect support and adoption signals.
2. Design choice: The team rejected autonomous outreach and chose internal action preparation because external communication was difficult to reverse.
3. Pre-release evidence: Scenario evidence supported the relevance claim for high-priority accounts. A synthetic retry test suggested duplicate proposals were contained.
4. Pilot: Five percent of eligible accounts entered the workflow. Approval time was nearly twice the laboratory estimate, so exposure was limited to accounts with named owners.
5. Production incident: After a connector outage, replayed events received new transport identifiers and generated duplicate proposals against unchanged account situations.
6. Containment: The team stopped proposal creation, cancelled open duplicates, and retained the external-send prohibition.
7. Correction: Deduplication moved to business-situation identity, approval revalidated current state, and replay behavior became release evidence.
8. Current state: Prepared internal actions operate for high-priority, named-owner accounts. External communication remains manual.

Representative system trace

An eligible account event enters with transport identity and source time. The system resolves durable account and situation identity, reads current permitted account context, and checks for an open, completed, cancelled, or expired action for the same situation. It may prepare a proposed task and draft. The account owner sees the evidence and current state, then chooses whether to create the internal task. Immediately before that effect, the harness revalidates identity, eligibility, cancellation, and ownership. The owner separately decides whether and how to contact the customer through the ordinary communication system.

State and effect require separate treatment. A draft can be regenerated. An approved internal task must be deduplicated and auditable. A sent customer message remains outside the system's authority. Rollback stops future proposals but cannot erase a task that someone has already acted upon.

Evidence ledger

Failure and change analysis

The initiating condition was recovery from a six-hour connector outage. The connector replayed source events with new transport identifiers. Latent conditions crossed several layers: deduplication equated transport identity with business identity; proposal state was written before the current account situation was revalidated; synthetic evidence preserved identifiers; and the approval interface grouped work by created time rather than account situation. Some managers approved a second internal task because the earlier task was not visible in the same view.

The violated invariant was: one active internal action may exist for one account situation, regardless of event delivery history. Over two hours, the system created 126 duplicate proposals and 18 duplicate internal tasks. No duplicate customer messages were sent because the system lacked send authority and account owners retained communication authority. Queue-volume monitoring detected the surge after 23 minutes; it did not initially identify business duplicates.

The team stopped proposal creation, cancelled unapproved duplicates, notified owners of the 18 created tasks, and reconciled account histories. Recovery evidence showed one active action per situation and no external messages attributable to the duplicate tasks. Durable changes introduced business-situation idempotency, pre-effect state revalidation, situation-grouped approval views, replay tests with transformed transport identities, and a direct duplicate-situation signal.

Residual risk remains when two distinct events appear to describe the same business situation or when account ownership changes during approval. The operations owner accepts delayed or suppressed internal preparation in ambiguous cases; the safe response is manual investigation, never autonomous customer contact.

Outcome and transfer

For exposed high-priority accounts, missed internal follow-up fell from 16 to 9 percent over six weeks. Managers edited 34 percent of prepared tasks, discarded 17 percent, and approved the remainder. Live approval consumed more time than forecast, so the team did not expand to accounts without named owners. There was not yet sufficient evidence that the workflow improved renewal or customer satisfaction; the product claim remained operational follow-up, not business outcome.

This tool failed materially even though every generated sentence could have been acceptable. Business identity, durable state, approval presentation, and replay evidence jointly determined the duplicate effects. The authority boundary kept an internal workflow incident from becoming duplicate customer contact. The lesson transfers to asynchronous workflows only when business identity is stable, cancellation is explicit, state is revalidated before effect, and a usable manual path remains. The transport key, account threshold, and queue target do not transfer. Connector semantics, the ownership model, or any proposal to add send authority reopens the decision.

7. Failure Modes

Across the four cases, the same system failures recur beneath very different undesirable outputs.

Authority and validity are confused

The support case shows how an authoritative source can still be stale. In the migration case, a valid historical record could explain the past without authorizing a present action. The system needs authority for the current decision, not a generic trusted-source label.

Missing evidence becomes negative evidence

The claims system initially interpreted unreadable attachments as absence of urgency. That mistake becomes especially dangerous when missing evidence concentrates in a consequential population. Unknown, absent, and negative are different system states.

Human control exists on paper but not at load

Support agents detected fewer unsupported claims after sustained review. Claims specialists could not staff the widest proposed queue. Customer-success approval took almost twice the laboratory estimate. A human gate without queue evidence and a safe overload path creates latent autonomy.

Component identity is mistaken for system identity

Repository revision meant little without migration-contract identity; transport event identity could not replace business-situation identity; citation presence did not establish source validity. Effective system identity includes the contracts that give component behavior meaning.

Pre-release evidence omits the production mechanism

Synthetic retry evidence preserved transport identifiers. Claims evidence underrepresented handwriting extraction. Support review studies only partially represented fatigue. The missing mechanism, not the aggregate score, determined the operational failure.

Rollback is assumed to undo effects

Disabling a release prevents new behavior; it does not unsend a response, erase a reviewed patch, restore claim time, or cancel work already acted upon. Consequence boundaries and correction paths must be designed before exposure.

Analysts face a corresponding risk: hindsight can make every latent condition appear obvious. A fair case asks whether the condition was discoverable with proportionate evidence at the time and whether the owner recorded the assumption that later failed.

8. Tradeoffs

The same architecture label produces different decisions as consequence, authority, state, evidence delay, and human capacity change.

Across the portfolio, consequence and reversibility constrained authority more than model capability did. Evidence delay weakened the claims available for triage. Durable state made event replay more consequential than retrying a synchronous answer. Human capacity narrowed three systems even when offline quality looked acceptable. Volatile dependencies—policy publication, repository evolution, extraction, and connector semantics—determined which identities belonged in effective releases and operating signals.

No single side of these tradeoffs is generally correct. The decision is defensible only while its evidence, owner, and reopening condition remain current.

9. Production Checklist

Before accepting a case analysis as review-ready, confirm:

• [ ] Provenance, time horizon, confidentiality transformations, illustrative figures, and uncertainty are explicit.
• [ ] The baseline workflow, product responsibility, affected parties, consequence, constraints, unknowns, non-goals, and minimum useful outcome appear before the architecture.
• [ ] The authority boundary names the first irreversible or externally consequential effect and what the system refuses to do.
• [ ] At least one credible simpler, non-AI, less-autonomous, or differently structured alternative is compared.
• [ ] Material decisions record the trigger, evidence available then, accountable owner, accepted risk, reversibility, rationale for rejection, and reopening condition.
• [ ] The timeline distinguishes decision-time belief from facts learned through evaluation, operation, failure, or delayed outcomes.
• [ ] Earlier chapter artifacts are referenced only where their contracts change the case; at least one cross-artifact tension is resolved explicitly.
• [ ] A representative end-to-end flow makes context, identity, control state, human authority, effect, evidence, and correction boundaries legible.
• [ ] Evidence ledgers connect claims and populations to limitations and actual scope decisions, including disconfirming evidence.
• [ ] Human review or approval names role, authority, evidence, skill, capacity, queue, timeout, escalation, and safe overload behavior.
• [ ] Failure analysis identifies initiating and latent conditions, invariant, causal chain, affected population, detection gap, containment, recovery proof, durable correction, and residual risk.
• [ ] Outcomes compare with the baseline and include quality, consequence, latency or cost, adoption or override behavior, operating burden, current scope, and unresolved limitations.
• [ ] The counterfactual explains what would have happened under the strongest rejected option.
• [ ] Transfer claims state preconditions, non-transferable details, uncertainty, and revalidation triggers.
• [ ] The case does not introduce a new framework or re-teach methods owned by another chapter.

10. Design Review Questions

1. Which fact or constraint eliminated the most obvious alternative?
2. What did the team believe when it made the decision, and what did it learn only later?
3. Was the chosen responsibility narrower than the model's apparent capability? Why?
4. Which accepted risk had a named owner, expiry, and reopening condition?
5. Which inherited artifact or contract constrained another, and how was the conflict resolved?
6. What was the first irreversible or externally consequential step?
7. Could the human control detect the target failure at the actual arrival rate, or did it merely approve work?
8. Which evidence changed scope rather than merely reporting performance?
9. Which important population or mechanism was missing from pre-release evidence?
10. What invariant was violated, where should it have been enforced, and why was the violation not detected sooner?
11. Could the failure recur through a different source, identity, state, or release path after the fix?
12. What did rollback not undo, and how were affected parties corrected or made whole?
13. Did the realized workflow benefit justify the ongoing review, stewardship, and exception burden?
14. What would cause expansion, contraction, suspension, or retirement of the current scope?
15. Which part of the lesson transfers, under what preconditions, and what should not be copied?

11. Main Artifact: Case Study Analysis Format

The Case Study Analysis Format is one coherent decision record, not a stack of blank templates. Chapter 14 packages reusable working forms. This chapter defines the analysis those forms must preserve and demonstrates it in the four completed cases.

Artifact control and source-decision trace

A completed case identifies its Case Study Analysis Format version, record ID, provenance class, analysis owner, review date, validity limits, and reopening event. When an earlier decision materially constrains the case, the trace also names the source artifact and version, the accepted decision or condition consumed, and the later evidence that confirmed, narrowed, contradicted, or reopened it.

The trace is monotonic. A case may justify narrowing, suspending, superseding, or reopening an earlier decision, but it cannot retroactively broaden that decision's scope, population, authority, accepted risk, guarantee, or validity. Only a new decision in the owning artifact can do that.

The downstream handoff to the Complete AI Systems Engineering Toolkit is a set of exact record references, findings, evidence limitations, change impacts, and reopening requirements. Chapter 14 may package those records into a Change Review Packet; it does not replace the case's causal analysis or silently convert a local lesson into an approved general rule.

View 1: Case identity and provenance

Identify whether the case is historical, anonymized, composite, or illustrative. Add its time horizon, material confidentiality transformations, constructed figures, and remaining uncertainty. Those facts keep invented precision or a sanitized narrative from masquerading as universal evidence.

View 2: Decision context

Describe the baseline workflow, proposed responsibility, actors and affected parties, consequence and reversibility, workload and latency, source-of-record constraints, operating capacity, assumptions, unknowns, non-goals, and minimum useful outcome. Case 1 demonstrates the view by separating standard-product drafting from policy-sensitive communication before selecting the assistance pattern.

View 3: Decision timeline

For each consequential point, record:

The support case applies this view from initial workflow evidence through exclusion, staged exposure, incident containment, and resumed bounded scope.

View 4: Option record and counterfactual

Capture the trigger, credible options, selection criteria, supporting and disconfirming evidence, selected option, rejection reasons, accepted cost, and reopening condition. The strongest rejected option needs an operating model, not just a label. In Case 3, automated routing would have reduced manual route selection while transferring asymmetric error into a weakly evidenced, delayed-label decision. That counterfactual—not a generic preference for human review—explains the narrower priority-assistance choice.

View 5: Integrated system trace

Follow one representative input or event through:

1. durable identity and eligibility;
2. permitted data or context and its authority;
3. instruction or decision contract where material;
4. harness state, validation, fallback, and stop condition;
5. tool or action authority;
6. human evidence, decision, and capacity;
7. external or durable effect;
8. release and evidence identity;
9. correction or recovery path.

At each seam, reference the relevant artifact from Chapters 3–12 without reproducing its method. Case 4 follows an account event through business-situation identity, proposed state, owner approval, internal-task creation, and a separate external-communication boundary.

View 6: Evidence ledger

All four completed cases include this view. Together they show evidence enabling a bounded launch, blocking broader authority, exposing an ineffective control under load, and overturning a pre-release retry assumption.

View 7: Failure and change analysis

Failure analysis covers the initiating condition, latent conditions, expected invariant, enforcement point, propagation, affected population, consequence, first reliable signal, missing or misleading signal, detection delay, containment, recovery proof, durable correction, residual risk, and owner. The support incident is the fullest demonstration: an indexing omission, mismatched eligibility timing, permissive drafting contract, reviewer fatigue, and incomplete telemetry combined to expose customers to obsolete guidance. No single model-error label explains that chain.

View 8: Outcome and transfer record

Close with:

• baseline comparison and observed period;
• quality and consequence by material population;
• latency, throughput, cost, and human effort where decision-relevant;
• adoption, editing, override, abstention, or abandonment behavior;
• control and stewardship burden;
• current scope, unresolved limitation, and residual risk;
• local observation and plausible causal interpretation;
• design change produced by the evidence;
• bounded lesson and transfer preconditions;
• non-transferable details and competing explanations;
• expansion, contraction, retirement, or revalidation trigger.

Case 2 demonstrates why this view must preserve limits: the evidence supports explanation and two migrations in repositories with enforceable permissions and owned tests. It does not support autonomous change or broad patch generation.

Together, the eight views let another engineer reconstruct the decision instead of merely admiring the result. Completeness comes from causal, reviewable links among the views—not from filling every field with prose.

12. Key Takeaways

• Architecture should be judged against the responsibility and credible counterfactual available at the time, not against hindsight or model capability in isolation.
• Human authority contains risk only when the reviewer has evidence, skill, capacity, independence, and a safe overload path.
• Source validity, business identity, control state, and effective release identity can determine outcomes more than output fluency.
• Evidence is useful when it changes scope. In these cases it enabled bounded drafting, restricted patch authority, rejected automated routing, and corrected event-replay assumptions.
• A no-build, delayed launch, or narrower responsibility can be the successful outcome of AI Systems Engineering.
• Rollback stops future behavior; it does not erase customer statements, elapsed claim time, reviewed work, or durable actions.
• Transfer the causal lesson only when consequence, authority, population, dependency volatility, evidence delay, human capacity, and reversibility are sufficiently similar.
• Reopen the decision when its recorded assumptions fail. A review-ready case ends with that trigger, not with a victory claim.