NotebookLM and Jupyter Notebooks: Import Code and Results

To use a Jupyter notebook with NotebookLM, export the relevant cells and saved results into a supported document such as Markdown or PDF, then add that document as a research source. This gives the assistant an analysis snapshot; it does not connect it to your running Jupyter kernel. fenbs can keep the analysis links, approved findings, and remaining checks available when another assistant continues the work.

NotebookLM now appears as Gemini Notebook under Google’s official naming change↗ (opens in a new tab). Google’s supported-source documentation↗ (opens in a new tab) lists Markdown, PDF, and text, but does not list the Jupyter notebook file extension. Choose a documented source format instead of renaming an unsupported file.

How do you prepare an analysis for upload?

1. Save the original notebook and identify the analysis version you intend to discuss. Note the input dataset and the date or version of the results.
2. Review the cells and saved outputs. Remove secrets, personal records, and material you do not have permission to upload from the copy you will share.
3. Export a readable report using Markdown for text and code, or PDF when the relationship between plots, captions, and tables matters.
4. Open the exported document yourself. Confirm that the relevant code, output values, axis labels, and explanation survived the conversion.
5. Add the document as a notebook source. Ask a small question with a known answer and compare the response with the original analysis.

The main quality check happens before uploading. If an output table is clipped, a chart has no units, or the report contains an old execution result, the assistant starts with an incomplete record. A readable export is part of the evidence, not an administrative extra.

Which export format should you choose?

Jupyter’s nbconvert documentation↗ (opens in a new tab) describes the available export commands. Its Markdown export writes images into a separate folder, while PDF export has additional dependencies. Do not assume that uploading a Markdown file also uploads every image referenced inside it.

jupyter nbconvert --to markdown analysis.ipynb
jupyter nbconvert --to pdf analysis.ipynb

These commands are examples to run in your own configured Jupyter environment. If PDF conversion reports a missing dependency, follow the converter documentation or use a supported export you can inspect. Avoid adding execution options merely to get past a formatting problem.

What does an exported notebook leave behind?

Jupyter notebooks combine narrative, code, and outputs. Jupyter describes this structure in its notebook format documentation↗ (opens in a new tab). A static report can present those elements, but it is not a running environment with access to your installed packages, current variables, private datasets, or local files.

Keep the original notebook and the data needed to reproduce the analysis in their appropriate storage locations. The report should say which run it describes and how a reviewer can locate the underlying work. An assistant’s explanation of a function is not evidence that the function executed successfully on your data.

For example, say a designer is reviewing survey responses. The export may explain a satisfaction chart, but it cannot establish whether duplicate responses were removed unless the methods and relevant outputs show that step. Ask for the missing check instead of letting the assistant fill the gap with a plausible assumption.

Keep the report URL, original analysis location, and version note together in fenbs Links and listings, so the next assistant knows which evidence it is discussing.

How should you ask questions about code and results?

Give each analysis section a descriptive heading before export. Use questions such as “What filter produced the regional totals in the Results section?” or “Which assumptions are stated for the forecast?” These are easier to check than an instruction to find every problem in a long notebook.

Separate three tasks: explaining what the saved code says, interpreting a saved output, and verifying a fresh calculation. The first two can use a readable source snapshot. The third needs an actual calculation in a suitable environment and a review of its inputs.

For help inside the coding environment, see GitHub Copilot in Jupyter notebooks. That workflow serves a different purpose from preparing a research source for discussion.

How do you prevent a stale result from becoming a rule?

Label exports with a clear version and describe changes when you replace them. If the dataset changes, revisit the conclusions that depend on it. A correct explanation of last month’s snapshot can still be the wrong basis for today’s choice.

Record what a person actually approved, including the scope and reason. A finding such as “this sample suggests longer delivery times” should not silently become a general instruction to change every delivery estimate. In fenbs Decisions and rules, a human decision can remain separate from the supporting analysis and unresolved questions.

How to keep analysis follow-ups with fenbs

1. Create a free account and add a project for the analysis.
2. Save the exported report and original notebook references in Links and listings, including version labels.
3. Add checked conclusions as AI context notes. Record a human approval in Decisions and rules only when that approval has actually happened.
4. Create tasks for reruns or missing checks, and save Where we left off before changing assistants.

fenbs does not execute your Jupyter notebook or replace data storage. It is not the right fit for running experiments; it helps retain the work record around them. If you only need to explain one saved chart, a clean export and a checked answer may be enough.

For other research environments, compare NotebookLM alternatives or Claude Projects and NotebookLM. More source-handling guides are collected under AI at work.