D683 Advanced AI and ML, catalog number ICSC 3113, is the three CU course in the WGU School of Technology built around a hands on project designing and developing artificial intelligence and machine learning solutions for real world business problems. The phrase real world business problems is the part students underweight. A technically strong project aimed at a problem no organisation has is a returned submission.
The business framing is scored, not assumed
Project courses in the School of Technology tend to distribute their aspects across two halves that students weight very differently. The technical half asks whether the solution is competently designed, implemented and evaluated. The applied half asks whether it addresses a real problem, whether the metric reflects what the business cares about, and whether anyone could actually use the result.
Students typically deliver eighty percent of the technical half and thirty percent of the applied half. The fix is inexpensive: state the decision the model supports, the cost of each kind of error, the volume at which it would run, and who acts on the output. Those four sentences reframe an exercise as an application, and they are usually enough to lift several aspects.
The second scored theme is design rather than implementation. Advanced work is expected to show that alternatives were considered and rejected with reasons, that the data was interrogated rather than accepted, and that the evaluation was chosen to match the decision rather than taken from the default in a tutorial. A project that reads as a competent execution of one approach with no visible alternatives scores lower than a slightly weaker project that argued its way to a choice.
Turning scored aspects into a section plan
The scoring detail sits in your Course of Study rather than the catalog. Count the aspects and treat them as your outline. Each is judged independently on a three point scale and each needs a 2, so a strong model with a thin problem framing is a returned task rather than a middling one.
Project submissions mix narrative, code and outputs. Decide in advance which aspects are answered where, and name the artefacts in the narrative so scoring does not depend on the evaluator opening a notebook and inferring your intent.
The word budget, worked. Assume seven scored aspects and about 2,000 words of narrative outside the code. Reserve 150 words for an opening that names the business problem and 130 for a close. That leaves near 1,720, about 245 per aspect. Then take 60 words from each of two implementation aspects and give 120 to the problem framing aspect and 120 to the evaluation aspect. Implementation detail is easy to write at length and it is the least differentiating material in the submission.
A structure that fits an applied AI project
Where your directions specify a structure, follow it. Where they do not, this ordering matches how project aspects tend to be scored.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Business problem | The decision, its frequency, its cost, and who owns it | Frames whether any of the technical choices were correct |
| Success criteria | What the solution must achieve to be worth deploying | Set before modelling, or the evaluation is unfalsifiable |
| Data | Source, quality, bias, coverage and what is missing | Interrogation rather than description is what scores |
| Design | Approach chosen, alternatives rejected, and the reasons for both | The clearest evidence of advanced rather than introductory work |
| Implementation | The build, with the parts that required judgment called out | Kept shorter than students expect |
| Evaluation | Metrics chosen to match the decision, against a baseline | A default metric on an asymmetric problem is a scored weakness |
| Deployment and risk | What using this would require, and who could be harmed if it is wrong | Expected at this level; its absence is conspicuous |
Write the success criteria before building anything and do not revise them afterwards. Criteria adjusted to match the result you obtained are visible to anyone who has read a few of these projects.
Evidence craft for a project submission
Project work generates evidence continuously, and the strongest submissions capture it as they go.
- Report every metric with the split it was computed on and the baseline it is compared against.
- Document the data as it arrived, including what you discarded and why, since sample selection changes what the conclusion is about.
- Keep a short decision log so design justifications are written from notes rather than from memory.
- Cite methods to research sources rather than to library documentation.
- Record versions and seeds so results are reproducible, and say what varies between runs.
- Use APA throughout and keep quotation short.
Name the population your solution does not cover. Every dataset excludes somebody, and stating who, plus what that means for deployment, satisfies risk aspects with evidence rather than with reassurance.
What separates Competent from a submission sent back
Independent aspect scoring keeps returns narrow, and here they cluster on framing and evaluation.
- The business decision is named and quantified, at least approximately.
- Success criteria were set in advance and are reported against honestly.
- At least one alternative approach is rejected with a reason tied to this data.
- Metrics match the asymmetry of the decision rather than defaulting to accuracy.
- Deployment requirements and risks are addressed rather than assumed.
Performance assessment work can be revised and resubmitted with no grade penalty, so a return costs time rather than standing. Terms run six months at a flat rate, and project courses consume calendar unpredictably, which makes early framing work the highest value hours available.
Six mistakes that cost time in D683
- Choosing the dataset before the problem. It produces a project that cannot explain why anyone would want the answer.
- Criteria written after results. They always look satisfied, and the pattern is recognisable.
- Default metrics on asymmetric problems. Where one error costs far more than the other, a symmetric metric hides the failure that matters.
- No rejected alternatives. A single approach with no comparison reads as the only approach you knew.
- Data accepted uncritically. Coverage, bias and missingness are part of the design argument, not preliminaries.
- Stopping at the metric. What deployment would require is part of the assessment at this level.
- Using information at training time that would not exist at decision time. A field populated only after the outcome is known produces an excellent model and a useless one, and it is the most expensive error in applied work because it is invisible until deployment.
Turning a technical project into an applied one
The cheapest improvement available in D683 is a properly written framing section, and it can be produced in an hour from four questions.
What decision does this change? Not what does it predict, but what does somebody do differently because of the prediction. If the honest answer is nothing, the project has a problem that no amount of modelling will fix, and it is better to discover that in week one.
How often is that decision made, and by whom? Volume determines whether automation is worth building at all, and the identity of the decider determines what the output has to look like. A model whose output is a probability, handed to someone who needs a yes or a no, has an unfinished interface.
What does each kind of error cost? This is the question that sets the metric and the threshold, and it is the one most often skipped. If missing a case costs a customer and flagging a case costs five minutes of staff time, the operating point is nowhere near the one that maximises a symmetric score, and saying so demonstrates applied judgment directly.
What would have to be true for this to be used? Data available at the moment of decision rather than only in hindsight, latency the process can tolerate, an owner who can act, and an explanation good enough for whoever is affected. Each of those is a sentence, and together they turn a modelling exercise into the applied solution the course description asks for.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: a framing section that names the decision and its costs, success criteria written in advance, a design section with rejected alternatives, evaluation matched to the decision, and a deployment and risk section. Plus a walkthrough so the project is yours to present.
D683 is one of the heavier applied courses in the programme for elapsed time. Terms are six months at a flat rate, so scoping the project narrowly at the start is what keeps it inside one.
Questions students ask about D683
Is D683 the same course as ICSC 3113?
Do I need real business data for the project?
Can you build the project for me?
Where D683 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.