Two Pipelines

Any single tool here gives you a good session; a pipeline gives you a system, where each stage's output is the next stage's input and there is an artifact at every joint. Five good sessions leave you with five chat logs and the job of gluing them together in your head. A pipeline leaves you with a result you can hand someone, and a trail showing how it got made.

• Run a literature review from research question to drafted review without leaving the toolchain.
• Run an ML experiment from framing to queryable results, with artifacts at every stage.
• Explain what source-grounded Q&A prevents and what it does not.
• Identify the handoff points where a chained pipeline breaks, and instrument them.

Everything from Units 02 through 05, in sequence. The guide's framing is that the real value of the suite is chaining, and both pipelines below are its examples, expanded.

NotebookLM is the piece that has not appeared yet. It answers only from the sources you upload and cites them, which means it cannot invent a reference. That property is the reason it belongs in a literature pipeline and not a general one.

Pipelines rarely fail in the middle of a stage; they fail at the handoffs, where context quietly drops on the floor between tools. §2.4's answer is to make the context a durable artifact (files, specs, structured outputs) so each tool picks up what the last one actually knew instead of a summary of it.

§7.4 (The data analyst leveling up) is the closest existing worked example. §5.6 (API design for vibe coders) matters once your experiment needs to be callable by something else, and §2.4 (Context engineering) is what keeps the handoffs from losing state.

/stacks/rag-knowledge-app is the literature pipeline built properly, with retrieval you control. /stacks/aws-production is where the experiment pipeline goes when it needs to run without you.

Lab A: Literature review

1. Run two or three Deep Research passes on your topic, each from a deliberately different angle. Edit every plan.
2. Export each report to Google Docs.
3. Add the key papers (the actual PDFs, not the summaries) to a NotebookLM notebook.
4. Ask NotebookLM questions that require reading across the sources. Check its citations against the papers.
5. Back in Gemini, attach the notebook and ask it to synthesise gaps across the sources.
6. Draft the review in Docs using the Gemini side panel pulling from @Drive.
7. Find one claim in your draft that no uploaded source supports. Trace how it got there.

Lab B: ML experiment

1. Frame the research question and experimental approach in Gemini Advanced.
2. Switch to gemini-cli and scaffold the training pipeline from your project GEMINI.md.
3. Push to GitHub.
4. Open Colab, connect to your Drive dataset, and use the Data Science Agent for exploratory analysis.
5. Train on the GPU tier you sized in Unit 05. Checkpoint to Drive.
6. Save results to Drive in a structure you can query later: one folder per run, with the model version and prompt logged alongside.
7. Ask @Drive summarise my latest training run results in Gemini and confirm it can actually answer across runs. If it cannot, your output structure is the problem.

One pipeline completed end to end, with the artifact from every stage retained: the edited research plans and reports, or the spec, repository, notebook, checkpoint, and queryable results directory.

• NotebookLM cannot hallucinate a citation. What can it still get wrong?
• At which handoff did your pipeline lose the most context, and what would fix it?
• Your @Drive query could not compare two training runs. What was wrong with how you saved them?
• Which stage of your pipeline would break first if you re-ran it in six months?