D604 Advanced Analytics, catalog number DTAN 6216, is the three CU course in the WGU Master of Science, Data Analytics that extends the degree past classical machine learning into broader artificial intelligence: neural networks, deep learning and natural language processing. The technical ceiling rises here, and so does the risk of a submission that produces impressive output nobody can explain.
Explainability is the scored skill
The uncomfortable feature of deep models is that they work before you understand them. You can assemble an architecture from a tutorial, watch a loss curve fall, report a strong metric and have no defensible account of why any of it happened. DTAN 6216 rubrics are built to catch exactly that gap.
What gets rewarded is a chain of stated reasons: why this architecture rather than a simpler model, why this many layers, why this activation, why this stopping point, and what evidence you have that the network learned signal rather than memorising the training set. A single sentence explaining why a simpler approach was rejected does more for a graduate score than an extra layer ever will.
Natural language work carries its own version of the problem. Text has to be turned into numbers before a model sees it, and every step of that conversion is a decision that changes the result. Tokenisation, casing, stopword handling, stemming, embedding choice: a submission that silently accepts library defaults for all of them has quietly outsourced its most consequential reasoning.
Turning scored aspects into a section plan
The scoring detail is in your Course of Study, not the public catalog. Count the aspects there and treat the count as your outline. Each is judged on its own against a three point scale and each needs a 2, so a strong network with a thin justification section is a returned task, not a compromise score.
Advanced analytics tasks usually mix narrative with a substantial artefact. Name the artefact explicitly in the narrative when an aspect is satisfied inside it. A training loop that demonstrates regularisation is worth nothing to a scorer who cannot tell that is what it demonstrates.
The word budget, worked. Assume six scored aspects and about 2,000 words of narrative outside the code. Reserve 160 words for an opening that names the task and the data modality, and 120 for a close that states what the model supports. That leaves roughly 1,720, about 285 words per aspect. Then take 80 words from each of the two descriptive aspects and hand 160 to architecture justification and the remainder to overfitting evidence. Those two are the aspects where a deep learning submission is either graduate work or a tutorial retyped.
A structure that fits an advanced analytics report
Follow your directions where they specify structure. Where they leave it open, this order tracks how the aspects tend to be scored.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Problem framing | The task, the data modality, and why an advanced method is warranted at all | A deep model on a problem a regression solves is a scored weakness |
| Data representation | Encoding, tokenisation, embeddings, augmentation, each with a reason | The most consequential section in language and image work |
| Architecture | Layers, activations, loss and optimiser, with rejected alternatives named | Scored for reasoning; copied architectures are recognisable |
| Training regime | Epochs, batch size, learning rate, early stopping, regularisation | Checked for whether choices were made rather than inherited |
| Evidence against overfitting | Training versus validation behaviour, and what you did when they diverged | The single most reliable marker of a defensible deep learning task |
| Evaluation and interpretation | Metrics against a baseline, plus what the model appears to have learned | Interpretation is expected even when the model is opaque |
| Ethics and constraints | Bias in the training data, cost of error, compute and data requirements | Brief but expected; total silence here is noticed |
Keep a simple baseline in the report. A logistic regression or a frequency baseline next to a neural network is not a weakness in your submission. It is the only thing that makes the network's number mean anything.
Evidence craft for deep and language models
These models generate a great deal of output and very little proof. Supplying the proof is your job.
- Show the training and validation curves, or report both numbers per epoch. A final metric alone hides everything an evaluator wants to see.
- State the data volume honestly. Deep methods on small datasets need an explicit defence, not silence.
- Name the preprocessing decisions in text work individually, including the ones where you accepted a default, and say why the default was acceptable.
- Cite pretrained components properly: model name, version, source and licence, plus what it was originally trained on.
- Report compute conditions when they affect reproducibility, including hardware and run time.
- Use APA for external sources. Architecture papers are primary sources and citing them lifts the whole report.
State what the model cannot be trusted with. A classifier trained on one corpus does not transfer to another domain without evidence, and saying so before an evaluator asks is the cheapest credibility available.
What separates Competent from a submission sent back
Independent aspect scoring keeps returns local, and in this course they cluster around justification rather than implementation.
- The architecture section gives reasons that refer to this data, not to the paper the architecture came from.
- Overfitting is addressed with evidence rather than with the assertion that dropout was used.
- A baseline appears and is beaten, or is not beaten and that fact is discussed.
- Every representation decision in text work is named, including inherited defaults.
- The interpretation section says something about what the model learned, not only about how well it scored.
Performance assessment work at WGU can be revised and resubmitted with no grade penalty, so returns cost calendar rather than standing. In a six month flat rate term, a rebuild in a compute heavy course is one of the most expensive delays in the degree.
Six mistakes that cost time in D604
- Reaching for depth first. If a simpler model is competitive, the report has to explain why the complexity was worth it. Sometimes the honest answer changes your method.
- Reporting only final metrics. Without per epoch behaviour there is no way to show the model was not memorising.
- Accepting text preprocessing defaults silently. Casing and stopword handling change results, and unexamined defaults are an unexamined decision.
- No baseline anywhere. A neural network scoring 0.88 is unjudgeable until something naive is scored on the same split.
- Using a pretrained model without stating its provenance. What it was trained on determines what it can be used for.
- Skipping the ethics aspect. Two honest paragraphs about training data bias and cost of error are inexpensive and their absence is conspicuous.
Justifying the complexity you chose
The most useful question to ask yourself early in D604 is what a competent analyst without deep learning would do with the same data, and how close they would get. Answering it honestly does two things at once: it produces the baseline your evaluation section needs, and it forces the justification your architecture section is scored on.
Complexity has to buy something specific. For image data it usually buys spatial structure that a flat model cannot represent. For sequence and text data it buys order and context that a bag of words discards. For tabular data with a few thousand rows it frequently buys nothing at all, and gradient boosted trees quietly outperform the network while training in seconds. Saying that out loud, with numbers attached, is not an admission of failure. It is the analysis.
Where the advanced method does win, quantify the win and price it. A two point gain in a metric is worth having if the decision it supports is high volume and the cost of running the model is trivial. The same two points are a poor trade if the model needs specialised hardware, cannot be explained to a regulator, and has to be retrained every quarter by someone who has not been hired yet. Graduate analytics work is expected to hold both sides of that trade in view.
Practically, this becomes one short subsection: the simpler alternative, its score on the same split, the margin your method achieved, and a sentence on whether the margin justifies the operational cost. Three or four sentences, and they convert an architecture section from a description into a defence.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: representation decisions written with reasons, an architecture section that names rejected alternatives, overfitting addressed with evidence, and a walkthrough that leaves you able to explain the model rather than only run it.
D604 tends to consume more wall clock time than its three competency units suggest, because training runs are slow and rework is expensive. Terms are six months at a flat rate, so front loading the reasoning is the cheapest scheduling decision available.
Questions students ask about D604
Is D604 the same course as DTAN 6216?
Do I need a GPU for D604?
Can you train the network and hand me the results?
Where D604 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.