D804 Advanced AI for Computer Scientists, catalog number ICSC 6205, is the four-CU graduate course in the WGU School of Technology that synthesises what the earlier artificial intelligence and machine learning courses covered into applied work. Synthesis is the operative word and the reason the course reads differently: the scored question is rarely whether a technique works, but whether you chose the right one for a stated constraint and can defend the trade-off in writing. Students who did well on narrow modelling tasks often find this the harder course, because there is no single correct method to converge on.
What ICSC 6205 is actually testing
Method selection under constraints is the spine of the course. Real applied problems arrive with limits attached: latency budgets, small labelled datasets, interpretability requirements from a regulated setting, hardware that will not host a large model, data that cannot leave a jurisdiction. Advanced work is expected to name the binding constraint and let it drive the design. A submission that selects the most sophisticated available technique and then discovers it cannot be deployed has demonstrated the opposite of what the rubric asks.
Integration is the second demand. Applied artificial intelligence is a system, not a model: data arrives, is validated, is transformed, feeds a model, produces an output that something downstream consumes, and the whole loop needs monitoring because inputs drift. Aspects that mention design, architecture or implementation usually want the system view, including what happens when a component fails or a prediction is unavailable.
The third is consequence. At this level, ethical and societal analysis is not a closing paragraph. It means naming who is affected by a wrong output, which errors are asymmetric in harm, what recourse an affected person has, and what monitoring would catch the failure before people did. Written with specifics, it is one of the easiest aspects to satisfy. Written in generalities, it is one of the most common returns.
Turning scored aspects into a deliverable plan
The scoring detail lives in your Course of Study. Because D804 deliverables tend to be larger than single-model reports, the aspect list does more work here than in any earlier course: it tells you how deep to go on each component, which stops the common failure of building an elaborate prototype that satisfies two aspects and starves five.
Each aspect is scored independently against a three-point scale and each needs a 2. That structure rewards breadth over depth in exactly the way an integration course intends: an evaluator would rather see seven components adequately justified than one component engineered beautifully while the rest go unexplained.
The word budget, worked. Assume eight scored aspects and directions asking for roughly 3,000 words. Reserve 200 for an opening that states the problem and the binding constraint and 150 for a closing on next steps and monitoring. That leaves about 2,650, or 330 words an aspect. Then reallocate deliberately: the aspects covering method justification and consequences reward specificity, so take 60 from each of three descriptive aspects and hand 90 extra to each of those two. If a diagram carries part of the architecture, still write the two sentences that say what it shows.
Plan the build against the same list. Anything you construct that no aspect asks about is time spent outside the rubric, which is a luxury in a term measured by courses closed.
A structure that fits an applied AI deliverable
Follow prescribed headings where the task directions give them. Otherwise this arrangement tracks how integration and application aspects are usually scored.
| Section | What belongs in it | What earns the aspect |
|---|---|---|
| Problem and constraints | The decision to be supported, plus latency, data, interpretability and cost limits | Scored for naming the binding constraint rather than listing all of them |
| Approach comparison | Two or three candidate methods with what each costs and buys here | Scored for reasoning; a single option presented as inevitable is not a comparison |
| System design | Components, data flow, interfaces, failure behaviour | Scored for completeness; the unhappy path is what students omit |
| Implementation | What was built, what was stubbed, what libraries and versions | Scored for honesty about scope; stubs stated are fine, stubs implied are not |
| Evaluation | Task metrics plus system properties such as latency and resource use | Scored for evaluating the system, not only the model |
| Monitoring and drift | What is measured after deployment and what triggers retraining or shutdown | Scored where named; a specific trigger beats a promise to monitor |
| Ethics and impact | Affected groups, asymmetric harms, recourse, and uses ruled out | Scored for specificity anchored to this system |
| References | Techniques, datasets, standards and any regulatory source, APA | Scored where citation is named; regulated claims need sources |
One paragraph pays for itself in this course: a short statement of what you would build differently with twice the data or half the latency budget. It shows the constraint was genuinely load-bearing rather than decorative.
Evidence craft for an applied AI argument
Advanced applied work mixes measurements you produced, claims from literature and assertions about a deployment context. Each needs different handling.
- Measure the system, not only the model. Inference time, memory, throughput and cost per thousand predictions are evidence when a constraint was stated.
- Support comparative claims. If one method is described as more interpretable or faster, cite a source or show a measurement, and prefer the measurement.
- Keep the deployment context sourced. Statements about what a regulated sector requires need a citation, not an impression.
- Show the trade-off with numbers where possible. Two points of accuracy against a threefold latency increase is an argument; better and slower is not.
- Separate what was built from what was designed. Both are legitimate deliverables and confusing them is a credibility failure.
- Cite in APA throughout, including model cards, dataset documentation and any published benchmark you compare against.
Where you use a large pretrained system as a component, describe its limits as part of your system's limits. Inheriting a component means inheriting its failure modes, and saying so is exactly the analysis an advanced course expects.
What separates Competent from a submission sent back
Returns on D804 rarely concern the technology. They concern aspects answered at the wrong altitude, usually too abstract.
- A binding constraint is named early and visibly shapes later decisions.
- At least two approaches are compared on grounds that matter for this problem.
- The system description covers failure behaviour, not only the working path.
- Evaluation includes system properties as well as task metrics.
- Monitoring has a named trigger and an owner rather than an intention.
- The ethics aspect names groups, harms and recourse specific to this deployment.
Performance assessment work at WGU can be revised and resubmitted without a grade penalty, which makes an ambitious project survivable. What a return costs is calendar time, and a four-CU course at the end of a plan is usually the one standing between a student and a completed term. Where any part of the course is assessed by a proctored objective assessment, we prepare only, never sit it, and never ask for portal credentials.
Six mistakes that cost time in D804
- Choosing the method first and the problem second. Advanced courses reward fit, and a sophisticated technique defended only by its sophistication scores badly.
- Building far past the rubric. Extra components that no aspect asks about consume the time that thin aspects needed.
- Describing only the happy path. What the system does when input is malformed or the model is unavailable is part of the design aspect.
- Leaving the constraint decorative. A latency limit stated in the introduction and never mentioned again reads as ornament.
- Writing generic ethics. Concern about artificial intelligence in society is not analysis of your system.
- Underestimating integration time. Wiring components together consistently takes longer than modelling, and the write-up needs days of its own.
How support works on this course
Send the task directions and the scoring detail from your Course of Study, ideally before you build. What comes back is a scope plan mapped to the aspect list so the build stays inside the rubric, a comparison section that argues from constraints, a system description that covers failure behaviour, and an impact analysis written with named groups and specific harms.
For students finishing a graduate technology plan, this is often the course where pace matters most. Getting the scope right in the first week is usually worth more than any amount of extra engineering later, because the deliverable that closes is the one shaped like the rubric.
Questions students ask about D804
Is D804 the same course as ICSC 6205?
How is D804 different from the machine learning course?
Can you complete the project for me?
Applied AI project growing past what the rubric asks?
Send your task directions and your Course of Study rubric. You get a scope plan mapped to the aspects, a constraint-driven comparison and an impact analysis with real specifics.
Where D804 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.