D791 Integrating AI with Modern Software Applications is banner number ITSW 6108 and three competency units in the School of Technology, closing the graduate sequence. The catalog describes it as preparing students to analyze and explain the technical and analytical components of integrating AI into software applications. Analyze and explain are the graded verbs. This is the course about the seam: what happens when a component whose output is probabilistic is placed inside an application whose users expect it to work.
Integrating a component that is allowed to be wrong
Ordinary software components have contracts. Given valid input they return a defined output or an error, and the same input produces the same result. An AI component breaks both properties: its output is a probability distribution rather than an answer, and the same input can produce different results. Everything difficult about integration follows from designing around that fact rather than pretending it away.
The first design decision is what the application does with an uncertain answer. Accept it silently, show it with a confidence signal, route low-confidence cases to a person, or refuse to answer. Those are four different products, and choosing between them is a business decision informed by what a wrong answer costs. An integration that treats every output as fact has made the choice by default.
The second is where the component lives. A hosted service is fast to adopt and introduces latency, cost per call, rate limits, availability you do not control and data leaving your boundary. A self-hosted model gives you control of all of that and hands you the operational burden. A graduate paper is expected to state which and to say what the choice commits the organization to, in the same way any dependency decision would be argued.
The third is the failure design. What happens when the component is slow, unavailable, rate limited or returns something malformed. Timeouts with sensible defaults, a fallback path, caching where the same question recurs, and a circuit breaker so a struggling dependency is not hammered. None of this is specific to AI, and all of it is more necessary here because the component is remote, slow relative to the rest of the request, and priced per call.
Turning scored aspects into an integration design and budget
Each aspect is scored on its own and needs a 2. Here the aspects usually split between technical components and analytical ones, which is the catalog's own division, so sort them into those two groups first and gather different evidence for each.
Budget it. Suppose ten scored aspects and a document of about 2,000 words with an integration diagram. Dividing 2,000 across ten leaves 200 per aspect. Sort them. Two are diagram and component inventory aspects, needing 120 each, which is 240 and releases about 160. Two justify the integration approach and the hosting decision, at 300 each, or 600. Two cover handling uncertainty and failure, at 300 each, or 600. Two cover monitoring, evaluation and cost, at 220 each, or 440. Two short framing sections take 60 apiece, which is 120. That totals 240 plus 600 plus 600 plus 440 plus 120, which is 2,000, exactly on target, with the four argument sections carrying sixty percent.
Write the failure matrix before drafting: each failure mode of the component, what the user experiences, what the application does, and what gets recorded. Aspects about reliability are answered from that matrix and cannot be answered convincingly without it.
On the D791 integration task?
Send the aspects and the application context. You get an integration design, a failure matrix and a monitoring plan for a probabilistic component.
What an AI integration has to answer for
| Concern | The question to answer | Design response |
|---|---|---|
| Latency | How long can the user wait, and what if it exceeds that? | Timeout with a fallback, or an asynchronous flow with progress shown |
| Availability | What does the application do when the component is down? | A degraded path that still completes the user's task |
| Cost | What does a call cost and what happens at ten times the volume? | Caching, batching, and a budget with an alert |
| Uncertainty | How is a low confidence result treated? | Routing to a person, or an interface that presents it as a suggestion |
| Output validity | What if the response is malformed or out of range? | Validation at the boundary, with a defined response to failure |
| Data boundary | What leaves the organization with each call? | Minimization, redaction, and a stated retention position |
| Change over time | What happens when the model behind the service changes? | Version pinning where offered, and monitoring that would notice |
The last row is the one most often missed. A dependency whose behavior can change without your deployment is unlike any other dependency in your application, and a graduate paper should say how that risk is managed.
Evidence, safe handling and citation
Evidence for an integration is behavioral. Show the request and response shape with any sensitive content redacted, show what happens on timeout, show what the user sees when confidence is low. A table of test inputs with observed outputs, including the awkward ones, demonstrates that the boundary was exercised rather than assumed.
Handle data carefully in everything you submit. Never include real customer content, credentials or API keys in a document or repository, redact identifiers, and state that examples are synthetic. Where the integration sends data outside your organization, say so plainly and describe the minimization applied, because that analysis is part of what the aspects are asking for rather than a disclaimer.
For sources, provider documentation is authoritative for interface behavior, rate limits and pricing structure, and it changes, so cite with a retrieval date in APA where your program requires it. Established texts on distributed systems and resilience support the failure handling argument. Where you claim an integration pattern improves an outcome, ground it in a measurement or a cited result rather than in a vendor claim, and describe the capabilities of any service accurately rather than in the language of its marketing.
What clears, and what returns
Work at WGU is Competent or Not Competent with no letter grades and no ordinary grade point average, and a return costs revision time rather than a mark. In a six month flat rate term those days are the expense, and in a closing graduate course they are usually the days the capstone needed.
Documents that clear treat the AI component as a dependency with unusual properties and design accordingly. They state what the application does when it is slow, down or wrong. They give a cost model. They say what data crosses the boundary. They propose monitoring that would detect the component changing underneath them, which is the failure mode with no equivalent elsewhere in software.
Returns come from four habits. An integration described only in the successful case. Capabilities restated from marketing material rather than analyzed. No cost analysis in a per-call architecture. And uncertainty handled by presenting every output as a definite answer, which is the design decision the whole course exists to interrogate.
Six mistakes that cost D791 students time
- Designing only the happy path. A remote, slow, rate limited component fails often enough that the failure design is the design.
- No timeout. An unbounded call ties up a request thread and turns one slow dependency into an application-wide outage.
- Trusting the output shape. Validate at the boundary. A response that is usually well formed will eventually not be.
- Ignoring per-call cost. Architectures priced per request behave differently at scale, and omitting the arithmetic leaves a business aspect unanswered.
- Sending more data than needed. Minimization is both a privacy control and a cost control, and it belongs in the design rather than in a closing paragraph.
- Assuming the model stays the same. A hosted component can change behavior without any deployment on your side, and nothing else in your stack does that.
How we work on this course
Support for D791 is integration design. Send the scored aspects and the application context and you get an integration diagram with the boundary marked, a failure matrix covering slow, down, rate limited and malformed, an uncertainty handling decision tied to what a wrong answer costs, a cost model, a redaction pass for anything you submit, and a model document in the register WGU graduate evaluators expect. Where your course includes an objective assessment, our work is preparation only, and objective assessments are proctored: we never sit or assist during one, and we never ask for or use your WGU portal credentials.
This is a closing course in the sequence, and it draws on the architecture, delivery and security work before it. Terms are six months at a flat rate, so finishing it inside the term you planned for is what keeps the whole plan intact.
Three questions D791 students ask
Is D791 the same course as ITSW 6108?
How is D791 different from D789?
Do I have to build the integration?
Where D791 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.