NIC-6913 runs four class weekends and five quizzes between 22 August and 25 October. The dates are fixed, the room is ICC-B in Bethesda, and a missed quiz is a graded event. Nothing else on this site has that property, so nothing else gets to argue with it.

What that costs. The CS plan was written in August against an August calendar and has not been on it since. That gap does not close by being read every morning; it closes by re-basing the phase dates once, on a date that is already chosen — 26 October, the Monday after the last taught weekend. Until then CS is on a maintenance floor of about three hours a week, which is enough to stop it going cold and not enough to pretend it is the priority.

What it does not cost. Fitness is not a project and does not get paused for a term, because the thing that makes it work is that it never stops. What it gets instead is a split that already knows about the class weekends: sessions that fall on one are removed from that week rather than carried as a debt you were never going to pay.

Further out. The position is military, so nothing here ends the degree. Separation is roughly eighteen months away — spring 2028 — which puts the transition window (TAP, clearance disposition, the move) around spring 2027. Not a track yet; a date to have on the horizon so it is not a surprise.

Late work. Nothing higher than a B for the first 48 hours. After 48 hours it is an F, and a referral to the Dean of Faculty and Academic Programs. An extension has to be requested in advance and confirmed in writing — email or Blackboard message is enough. Trouble uploading is explicitly not a reason for a delay; you email it to Colligan and fix the upload afterwards.

AI. Different for every assignment, so it is written into each row. The Reading Review permits none at all. The Mid Term allows it to organise but not to write. Both briefs allow it for gathering data and producing graphics.

Attendance. More than one missed session in an eight-week term risks academic penalty or withdrawal. Eight sessions across four weekends means a missed weekend is two sessions.

Two approval gates. The STEM Summary Paper needs its topic approved by session 4 and the Formal Oral Presentation needs its NIC report approved by session 6. Neither is a deliverable, both are easy to miss, and together they gate 30% of the course.

One conflict to resolve with Blais. The schedule table says every assignment is due at the start of class; the submission section — and his mail of 22 August — say 2359 on the due date. Those are fourteen hours apart on a day you are in a classroom. This planner assumes the earlier one, which is the only assumption that cannot hurt you. Ask, and correct it.

Late work. Identical to 6122: nothing above a B for the first 48 hours, an F after that, and extensions must be requested in advance and confirmed in writing.

Two courses a term, four terms a year, so the six remaining courses are three terms: winter, spring and summer 2027. The thesis follows them. Nothing about that is tight — but nothing about it has slack either, and a term missed is a quarter added at the far end.

Spring is partly assigned already. MCR 701 runs for MEP students in the spring only, so one of the spring two is spoken for and the other is an elective. That makes winter the term that carries the last core, and summer the term that has to carry two electives with no core left to hide behind.

Four of the five remaining electives must be MSTI. One is free. Spend the free one deliberately rather than discovering in summer 2027 that it was used on whatever had a weekend section open.

RODC — Research Options for Degree Completion, AY2027. The route to finishing, and a decision rather than a form. It wants making while the faculty are still in front of you every three weeks, not in the quiet after the term ends.

MCR 701. Offered to MEP students in the spring only — confirmed by Dr. Bailey in July, after you asked about a weekend section in the fall. So the spring is already partly spoken for, and the open question is which research route it feeds rather than when to take it.

Not local. You are at FBNC, the classroom is at ICC-B, and all four weekends are in person, staying at hers in DC and driving the half hour out to Bethesda each morning — so the term costs roughly forty hours of driving on top of everything the two syllabi ask for, and no lodging. Those hours are on the travel blocks above rather than left implicit, which is why a class week reads as expensive as it actually is.

Every session, reading, weight, due point, approval gate, late policy and AI rule on this page is transcribed from the two syllabi rather than summarised. Where a syllabus says something exact, this page says it exactly.

The open question is 6913's due time. Its schedule table says assignments are due at the start of class; its submission section and Blais's mail of 22 August both say 2359 on the due date. This page plans to the earlier reading because that is the assumption that cannot cost you a grade — but it is an assumption, and one email settles it.

Two smaller ones: 6122's classroom is still listed as TBD, and the 6913 syllabus gives the presentation as due at session 10 (25 Oct) while the session entry asks for visual materials by 23 Oct. Both are on the page as written rather than reconciled by guesswork.

Around 2,600 kcal and 160–180 g of protein a day, which is maintenance at 162 lb on a push-up-led training week. A dinner or lunch portion here averages about 730 kcal and 48 g protein — estimates from raw-weight ingredient values, and the one figure you control is the cooking oil, at 120 kcal a tablespoon. Breakfast and the post-training food carry another 60 g of protein between them. That adds up without anyone counting, which is the only way it ever adds up.

Chicken is tenderloin — already cutlet-thin, so no knife and eight minutes in the air fryer — and never cooked past 160°F, because overcooking, not the cut, is what makes it chewy the second time — and it never lands on a three-portion night, where the last portion is reheated after tennis; on ground turkey because it is the fastest protein there is; on canned beans, tuna and eggs because they close a protein gap for almost nothing; and on a rice cooker because rice made while you are not watching it is the cheapest satisfying calorie in the kitchen.

Every session above has a 💬 note on it. Put the numbers in it — 5×14 HRP @ 40% or 6×400 @ 1:42 is enough. It syncs with everything else and it is what next week's session is written from.

The one number to keep current is the tested 2-minute push-up max, because every push-up prescription in the plan is a percentage of it. Retest at checkpoint 1 on 10 October, checkpoint 2 on 31 October, and on the record test. Between those, train the percentage and resist the urge to find out.

And the rule that makes the rest work: a repeated week is not a failed week. If a session was missed or the reps got ugly, run the same week again rather than taking the scheduled jump. The blocks are built to absorb that; what they cannot absorb is a percentage you did not earn being carried forward for five weeks.

Your Deep Agents build is the CS50P final project. Submit it as such if you want the certificate later. It's the only part of the course with no starter file, no given signature, and no spec — which is exactly why it's the real work rather than an assignment.

Tracing a bad answer backwards to retrieval-versus-generation is the single most useful skill in this domain, and most people conflate the two. Work down, never sideways:

Bad answer → Was the right evidence in the model's context? Yes → prompt or generation problem. No → was it in the search results? Yes → context-selection problem. No → was it indexed at all? Yes → retrieval or ranking problem. No → ingestion, extraction or chunking problem.

Do not touch the prompt until you know which box failed. Saturday's mastery challenge enforces this: five bad answers, prompt edits forbidden, fix retrieval instead.

The whole system reduces to six operations, and everything else is sophistication around them. By Sunday you write all six from memory: chunk_document, embed, index_chunks, search, build_context, answer.

Deliberately not this week: LangChain internals beyond the closing bridge, LangGraph, agents, MCP, fine-tuning, GraphRAG, multimodal RAG, Kubernetes, HNSW mathematics, cluster tuning, custom plugins, anything with a frontend. Know that graph RAG, agentic RAG and long-context-instead-of-retrieval exist; nothing more.

Six days before the trial, the employer said what the work actually is: integrating their existing retrieval-augmented generation system into another AI offering, starting with several days of reading both implementations, and arriving with at least a passing familiarity with RAG and OpenSearch.

The plan at that moment contained zero mentions of RAG, OpenSearch, chunking, reranking or hybrid search — and seven hours of Kubernetes operators, which the task description does not mention at all. Days 8 through 12 are now a single four-day bootcamp building one cumulative project: OpenSearch without RAG, then vector RAG end to end, then retrieval engineering against an eval set you write yourself, then production thinking and a cold rebuild from an empty directory.

The hours fit, once the travel is accounted for properly. Wednesday is a conference evening and gets two hours, no more. Thursday's 9–11 flight is two usable offline hours for the paper and mechanical work — the architecture drawing, the vocabulary, git — with the hands-on starting when you are home at 12:45. Friday is a full working day from 8 to 4, and the five-hour drive afterwards is additional time rather than a subtraction: ninety minutes of deliberate verbal work in the car and then music, because you will have been at a keyboard for seven hours. About 34 hours across the five days. Against eight-hour Thursdays and Fridays that leaves about three hours of slack — and that slack is buffer, not capacity. Day 2 runs long by design because PDF extraction is a swamp, and the plan's own rule is that hour markers are sequence rather than schedule. Let Friday bleed into Saturday rather than skipping a step. If it all runs clean, the optional closing item is LangChain's RAG tutorial, done last of all, so you can see which parts are the framework's framing and which are the machinery underneath — and that is your on-ramp back to Deep Agents.

The operator work is deferred rather than deleted, on the same terms as the four CS50P modules — genuinely useful, not on the critical path for the next six days. Day 10's first operator is the cheapest version of it and worth coming back to once the trial is behind you.

Async. CS50P never covers it, and both halves of this sprint assume it: the harness runs on an async runtime and kopf handlers are async def. Now an hour on Day 3.

Logging. A container has no console. Logs are the whole debugging surface on the cluster, and retrofitting them on Day 9 is miserable. Now Day 2.

In-code runaway controls. The one genuinely agent-specific risk. Step limits, tool timeouts, retry caps with backoff, a circuit breaker, a token budget checked in state. Day 4, before the first surprise rather than after it.

LangGraph underneath the harness. Deep Agents is a wrapper. If the team writes LangGraph directly, knowing only the wrapper is the gap that surfaces fastest. Ninety minutes on Day 11 building one graph by hand.

Provider swap and reproducibility. Point the harness at a different model — hosted or local — to find where that seam is, and make sure the repo runs from a clean clone. Both are Day 12, both are cheap now and annoying later.

The per-task minutes after the CS50P modules are budgeted for someone meeting this material cold. You aren't, on the infrastructure half, so expect to come in under on most of the build days. That's fine and it doesn't break anything: the pace meter compares budgeted minutes done against budgeted minutes expected, so finishing a 90-minute task in 50 still credits 90 and the verdict stays honest. Only the "hours done" figure overstates.

When a day runs short, the reclaimed time goes to the kata ladder rather than to finishing early — that's the weak point, and it's the one thing here a decisive fortnight will actually test. The ladder tops out at difficulty 4 on purpose, but if you're clearing those comfortably the next rungs are all-your-base and spiral-matrix (4), then forth and zebra-puzzle (5). forth is a stack-machine interpreter and the best reasoning exercise on the track at that level.

6.006 is an MIT sophomore course that lists discrete mathematics as a prerequisite, and lecture one opens with models of computation and proving solutions correct. Coming off CS50P you'd burn your energy fighting the framing rather than learning the structures — and the framing isn't what you're here for yet.

The Runestone book is built for exactly this gap. Its own preface says it assumes you may still be struggling with basics from a first course and are ready to go further anyway. It's Python, it's free, and the code runs in the browser, which suits how you learn better than a lecture hall recording does.

6.006 isn't discarded — it moves to week six, as a sharper second pass over material you've already built. Read that way it lands as tightening rather than teaching. And the proofs it does are the ones you'll be equipped for after Phase 02.

The argument above still stands: 6.006 is the wrong spine for this phase. What's been added since is a parallel lecture track, for weeks where leading with a lecture and using the book as reference suits you better. The spine is unchanged — Runestone, build first, drill second.

Read the table below before you rely on it. Two of the six weeks have no lecture behind them at all, and one has only half. A parallel track you assume is complete is worse than no track, because you find out in the week it fails you.

Where a week has coverage, watch the lectures instead of reading the corresponding Runestone chapter, not in addition to it. This phase specifies 55 of its 70 hours and the remaining fifteen are for debugging your own implementations — which is the learning. Adding a lecture track on top of the reading is how a twelve-hour week quietly becomes eighteen.

Weeks 2 and 5 are the ones to plan around. Recursion and graphs are both weeks where you'd be back on the book regardless, so don't schedule them expecting a lecture to carry you.

Handed an unfamiliar problem, your first instinct is to ask what structure it wants — and you're usually right.

The concrete test: twenty problem statements you haven't seen, and for each one you name the structure and justify the choice in a sentence, without solving any of them. If you're above sixteen, you're done. Below twelve, you skipped the implementing.

The standard failure mode is going straight to problem sites. You get fast at recognizing which structure a problem wants and never learn what the structure costs — so you can pick a hash table but can't tell me why it degrades, or why a poor key choice quietly turns your O(1) into O(n).

Writing your own is what makes the costs real. Every week here is implement first, drill second, and the drilling is much faster afterward because you're recognizing machinery you've already built.

Where the problems are. Every problem named in this phase is on LeetCode's free tier — search it by name, none of them are premium. NeetCode's practice list groups the same problems by topic, marks their difficulty, and has a free video walkthrough for most, which makes it the better front door. Use the roadmap for ordering and LeetCode for the judge.

Attempt in your own editor first, not the web one. Keep a drills/ directory next to structures/ in the same repo. That is not tidiness — it is so you can reach for the hash table you built rather than for dict. Solve it once with your own structure, then once with the built-in, and notice where yours is slower and why. That comparison is the entire reason this phase drills after building rather than instead of it.

Then paste into LeetCode to check. Their edge cases are the genuinely useful part — empty input, one element, duplicates, the enormous case that times out. That is what the site is for; the editor is not.

One timer for the session, not per problem. When it rings you stop, wherever you are. If you stall for twenty-five minutes on a medium, read the topic tag or the first hint — never the solution — and write down which stage you stalled at: understanding the problem, choosing the structure, or writing the code. After six weeks that log tells you what to fix, and it is more useful than the count of problems solved.

Each week's drill names specific problems in three tiers — easy, then medium, then hard — and they are meant to be done in that order. The easy ones are not filler: they are where you confirm the structure you just built behaves the way you think it does, and they should take minutes. The hard one is usually not finishable in the time allotted, and attempting it anyway is the point. Stop when the clock runs out, wherever you've reached.

This is still drilling after building, not instead of it. The rule above doesn't change — if you haven't written the structure from scratch, the problems teach you pattern-matching and nothing else, which is the failure this phase is arranged to avoid. Roughly eleven of the phase's fifty-five specified hours are drill; the ladder is there so none of that time goes on deciding what to attempt.

When you're stuck on a proof, the question is almost never "what's the clever idea." It's "which shape is this." Work down the table: can I go direct? Is the contrapositive easier? Is there a smallest counterexample to rule out? Is there a recursive structure to induct on?

Nine times in ten, choosing the right shape does most of the work, and the rest is bookkeeping.

Not typed. Handwriting is slower, and the slowness is the mechanism — you can't autocomplete your way past a step you don't understand. This is also the one phase where the assistant does the most damage. Struggling with a proof is how the skill forms; watching someone else's finished proof is how you learn to recognize proofs without being able to write one.

Hammack develops proofs the way you'd actually think them through rather than presenting them finished, and there are fully written-out solutions in the back. That combination is the whole reason it's the right book here — but only if you write your attempt before you look. Reading a worked proof feels like learning and isn't.

Given a recursive function, you can write a correctness proof by induction without a template in front of you.

The concrete test: take a recursive function you wrote in Phase 01 that you haven't proved anything about — the BST search, or the recursive flatten. State precisely what it returns, then prove it. Base case, inductive hypothesis, inductive step, no reference material. If you can do that in twenty minutes, Phase 03 will work.

This isn't hard math in the sense that decayed on you. There's almost no computation in it. It's careful argument — stating exactly what you're claiming, then showing it holds in every case rather than the cases you happened to test. That's structurally much closer to building an appellate argument than to integration by parts, and you already do the hard version of that professionally. What's unfamiliar is the notation, not the reasoning.

Two things are true about the difficulty. It genuinely feels foreign at first — expect roughly two weeks. And almost nobody quits after that point. The risk window is narrow and it's at the very start, which is why the first fortnight here is deliberately gentle.

Their proof course, CS103, states plainly that there are no math prerequisites — high-school algebra is enough. What it does require is the programming course before it, and it leans on recursion from that course throughout. That's the same ordering you're running: structures and recursion first, proof second, and no calculus anywhere near it.

They also run an entire optional companion course, CS103A, purely for extra proof practice and problem-solving strategy, described as existing because math is a skill that takes practice to develop. A university with Stanford's admissions bar staffs a support course specifically for this transition. The wall you're anticipating is real, institutionally acknowledged, and routinely got over.

Each week's twenty-minute task is the minimum; the better version is a small implementation that uses the week's idea on data you care about. Karatsuba on big integers. Dijkstra on your own dependency graph. Edit distance on two versions of a file you wrote. It takes an hour and it's the difference between having read about an idea and having used one.

Go down the list, not to your favourite. The single most common failure is reaching for dynamic programming when a greedy choice is provably safe, or reaching for greedy when it isn't — and the second one produces code that passes your tests and is wrong.

When you can't tell, write the brute-force recursion first. It's always correct, it makes the subproblem structure visible, and if the subproblems overlap you've just discovered you're in dynamic programming territory. That path is the whole design of weeks 3 through 5.

You can look at a proposed system and give a defensible answer on whether it scales — before it's built.

The concrete test, in three parts. Given an unfamiliar problem: name the paradigm and justify the choice. Write the recurrence and solve it for a bound. And when the honest answer is that no efficient algorithm exists, recognise that and propose an approximation instead of searching for one that isn't there. The third part is the one that separates this from interview preparation.

Erickson's Algorithms — the spine for this phase — states its own prerequisites plainly: discrete mathematics including predicate logic, sets, functions, recursive definitions, trees and graphs as abstract objects; and proof techniques including direct, indirect, contradiction, exhaustive case analysis, and induction, especially strong and structural induction.

That is Phase 02's syllabus, almost line for line. You'll arrive holding exactly the tools this book assumes, which is the difference between reading it and fighting it. Its author also notes it isn't suitable as a first course in data structures and algorithms — which is why Phase 01 came first.

When something is slow or wrong, walk down rather than sideways. Most debugging failure is staying at the language level — rereading your code — when the symptom is actually a cache miss, a page fault, a linker mismatch, or a cgroup limit. The symptom tells you the layer if you know what each one sounds like.

That's the whole reason this phase exists, and it's why the two layers you already met in Phase 00 sit near the top of the table rather than at the bottom.

You can profile something slow and form a real hypothesis about why, rather than guessing at the code.

The concrete test: take a program that's underperforming and, before changing anything, name the layer you think is responsible and say what evidence would confirm it. Then go get the evidence. Being right isn't the bar — having a falsifiable hypothesis instead of a hunch is.

Nothing depends on this and it has no prerequisites, so it's the one to pull forward if the math phases start to grind. But it also compounds harder than anything else with the work you'll have been doing since August: you borrowed ten hours of it back in Phase 00 to make containers legible, and this is where the layer underneath that arrives.

The through-line is the abstraction stack at the bottom of this page. Every layer hides the one below it until something breaks, and then the layer you don't understand is the one you're stuck in. By March there shouldn't be one.

The exit criterion for this phase is reading the linear algebra in an ML paper as description rather than as noise. That's a translation skill: the notation is dense, but it's describing operations on shapes, and the shapes are what you're building intuition for.

When you hit an unfamiliar expression, ask what it does to the space rather than what it computes. That question is answerable from four weeks of work; the arithmetic question mostly isn't, and mostly doesn't matter.

You can read the linear algebra in an ML paper as description rather than as noise.

The concrete test: open a paper on something you actually care about — retrieval, attention, embeddings — and read the equations. For each one, say what it does to the space in a sentence. You don't need to derive anything. If you can narrate the shapes, you're done.

Learn it geometrically, then implement it. Do not learn it as arithmetic. Most linear algebra courses teach you to row-reduce matrices by hand, which is the one skill you will never use and the one that makes people believe they hate the subject.

Every concept here has a picture attached — a matrix is a transformation of space, a determinant is how much it stretches area, an eigenvector is a direction the transformation doesn't rotate. Get the picture, then write the code, then let NumPy do the arithmetic forever after.

You can write gradient descent from scratch on a function of two variables — no library, no reference — and explain out loud what every term in it is doing and why the minus sign is there.

That single program uses all four things this phase exists to give you: derivative as rate of change, the chain rule, partial derivatives, and the gradient. If you can write it cold, you're done. If you can't, you know exactly which of the four is missing.

This was Phase 01 on the first draft, which was wrong. Nothing in data structures, proof, algorithms, systems, or linear algebra needs calculus — it's load-bearing only for probability and for reading the gradient in an ML paper.

Learning it first would have meant six months of decay before first use, on material that is pure intuition and therefore decays fastest. Here it sits one week ahead of Phase 07, which is the only thing that consumes it.

Read the middle column first and ask which one describes your situation. Almost everyone reaches for the normal distribution by reflex, and it's frequently the wrong answer — latency isn't normal, retry counts aren't normal, and assuming otherwise is how confident people produce badly wrong estimates.

When none of the stories fits, that's real information too: it means you should simulate rather than reach for a closed form. Which is the whole method of this phase anyway.

You can quantify uncertainty in a system you built, and you reach for simulation before you reach for a closed form.

The concrete test: take a claim you'd want to make about your own work — this agent is better, this change reduced latency, this failure rate is acceptable — and state it with an honest interval around it. Say how many observations you'd need to believe it, and what would change your mind. If you can do that without looking anything up, the core is finished.

Nine months, 383 hours, eight phases. What comes next is on the electives page: probe three in mid-May, then one concentration with real depth. Neuromatch's prerequisites are Python, linear algebra, probability, statistics and calculus — you'll have finished the last of those the week before their July cohort opens.

Worth doing on the last day: reread the plan page. Not for nostalgia — to notice which of the things that looked hardest in August turned out not to be, because that recalibration is what you'll use to scope the next thing you decide to learn.

Simulate before you derive. Every concept gets twenty lines of Python that generate the thing and count outcomes, run before you work through the algebra. You'll be nine months into a plan that started with Python; this is where that becomes a genuine mathematical advantage rather than just a skill you happen to have.

Bayes in particular clicks permanently the first time you simulate a counterintuitive result and watch the number arrive exactly where the maths promised. That experience is not available to someone learning this from a textbook alone, and it's most of the reason this phase sits at the end rather than the beginning.

Handed an unfamiliar system to design, you clarify the requirements before drawing anything, estimate before choosing, and can defend every component with what it costs rather than what it is called.

The concrete test: five designs run against a clock, out loud, with the retrospective written. If you are still rushing the requirements stage by the fifth, that is the drill — not more reading.

Most system design material is a question bank: memorise fifteen designs, recognise which one you have been handed. That works until an interviewer asks why, and it produces engineers who can name a pattern but not price it.

So the spine here is Kleppmann's Designing Data-Intensive Applications, which teaches the concepts underneath — replication, partitioning, consistency, the actual content of CAP — rather than the shapes on top. The question bank is week five, once you have something to reason with.

Timeouts, retries with backoff, circuit breakers and a token budget were Day 4 of Phase 00. Delivery semantics, idempotent consumers and backpressure were November's stack-gap weekend. Indexes, transactions and isolation levels were that weekend and Phase 01's SQLite work. Access control through a retrieval layer was the RAG bootcamp.

What you lack is not the ideas — it is their vocabulary, their failure analysis, and the reflex to price a choice rather than name it. That is a much shorter distance than starting cold, and it is why forty hours is enough here.

The concentration question and the business school question are the same question in different clothes. If the honest end state is research-adjacent work connected to neuroscience, an MBA is a strange instrument for getting there. If it's leading AI organisations, it's a very good one.

That's not a call anyone else should make. But notice the sequencing: probe one lands in early October 2026, probe two in March 2027, and the concentration in the summer. Every one of those produces information the Darden decision needs, and all of them arrive before it has to be made.

The worst version is deciding by default — letting the deadline choose because the probes never happened.

You described the three differently, and the difference is the useful signal. AI is a bet about where the world is going. Data science and economics is justified by what's already on your CV. Neuroscience is the only one you described in terms of wanting.

And "everything will be AI-adjacent soon" is an argument against AI as a concentration. If it becomes the substrate, it stops being the differentiator — and Phases 00 through 07 are its foundation regardless. The concentration is what you bring to it.

One caveat, added later. That argument originally rested on your already getting forty hours a week of AI at work. The premise now depends on how the August fortnight goes — the role is decided there, and January is only when it would start. If January lands, the argument stands unchanged. If it doesn't, you aren't getting those forty hours from anywhere, and AI as a concentration becomes a more serious candidate than this page currently allows. Worth rereading in January rather than assuming the conclusion survived.