NotebookLM for SRE: build a source-backed incident dossier

A source-backed notebook earns its place by making a disputed operational decision easier to resolve. Its answer should preserve conflicting instructions and their conditions, rather than compress them into one confident procedure. Current state and authorization remain separate inputs that a historical document collection cannot supply.

That is a useful role for Google’s NotebookLM-style notebook workflow: reading and comparing a bounded set of documents. It is not a substitute for live telemetry, a source owner, or authorization to act. Google’s current help pages use the name Gemini Notebook; this article retains NotebookLM in its title for readers looking for the established product name.

Build a dossier around one operational decision

Consider a hypothetical notebook containing an older restart runbook and a later review explaining that restart destroys diagnostic state. A neat synthesis that simply recommends restarting has removed the disagreement the responder needed to see. Ask for both passages, their dates, and the unresolved applicability question; route that question to the current service owner.

Choose a service and gather the current runbook, ownership record, SLO policy, dependency notes, and a few relevant incident reviews. Record each document’s owner, version, and effective date. Include known exceptions and superseded guidance when the purpose is to explain a change, but label their status clearly.

Before uploading, confirm that the account and workspace are approved for the material. Incident transcripts can contain customer information or credentials. Remove unnecessary sensitive details, and inspect current sharing and data-handling settings. Do not infer them from another Google product or another subscription.

Google’s notebook chat documentation describes source-based answers and citations. A citation offers a route to evidence; it does not establish that the cited passage is current, complete, or correctly interpreted.

Ask for a comparison you can verify

Begin with extraction and comparison before asking for a recommendation. A useful request is: “Compare the restart procedure in the current runbook with the recovery actions in these two incident reviews. Cite each supporting passage, identify contradictions, and say when the sources do not resolve them.”

Inspect every passage that would change an operational decision. Check whether a recommendation applies to the same component version and failure condition. A successful restart in one incident does not prove that restarting is safe when a different recovery job is in progress.

When sources conflict, ask for a small comparison with the document, effective date, applicable service version, and disputed instruction. That makes the disagreement reviewable by the runbook owner. Do not let the notebook settle it by counting how many documents repeat each instruction: several old incident reports can outnumber the one current exception that governs the action.

Use the gaps to improve the source material

If the assistant cannot find an escalation owner, verify the omission and repair the ownership record. If it conflates severity and ticket priority, clarify the terminology in the source and correct the generated output. These are useful discoveries even if the assistant never participates in a live incident.

The same approach can review a postmortem draft against its timeline. Ask where the draft claims a cause that the record only suggests, or where a decisive permission delay disappears from the narrative. A human reviewer still needs to assess whether a missing statement reflects a real omission or incomplete evidence.

Use document synthesis to expose the decision and its evidence, then resolve applicability and permission before turning the summary into an instruction.

A historical review can work from a fixed record. A live mitigation needs fresh state and current permissions; adding more old documents does not satisfy either requirement.

Keep live decisions outside a stale notebook

An imported document may not reflect a recent edit; source refresh behavior depends on the source type and current product workflow. Verify freshness rather than assuming synchronization. During an incident, compare any suggested action with the authoritative runbook and current system state.

Begin with one historical incident whose outcome you understand. Evaluate whether the notebook retrieves the right exception, preserves uncertainty, and refuses to fill a missing fact with plausible prose. The prompting guide for operators offers a broader pattern for this evidence discipline.

Image attribution retained from the source article: “A Student’s Reading Table in a home” by BabyBen98, CC BY-SA; cropped for header use.