How Notebook Generation Works

​

The short version

High IQ freezes the task input and source references for a generation run, enriches them with available TIWIH strain research, builds nine deterministic lessons, validates the evidence links, and publishes an immutable readable result. Evidence-first Report V2 additionally records a minimized immutable source snapshot and immutable validated publications. Its write and customer-update gates remain off while the readable experience is validated before launch. The readable notebook is the paid core. Optional media is not required for completion and cannot run unless its evidence, feature, and executor gates all pass.

​

The lifecycle

​

Using generation progress

You can swipe down or use Minimize at any stage. This closes the progress sheet only; generation continues in the background. A progress accessory remains available above the tab bar unless you dismiss it for that attempt, and tapping it opens the progress sheet again. If an update is running while an earlier notebook is still readable, Open Readable Notebook lets you keep learning without stopping the update. Canceling is a separate confirmed action. If cancellation is still being confirmed, High IQ shows that state; if the notebook finishes first, the app reports that it is ready instead of claiming it was canceled. Some stages show a measured percentage. Others use an indeterminate state because the pipeline does not yet have a trustworthy numeric measurement. High IQ does not turn a missing measurement into a made-up percentage or time estimate. Staging is intentionally full access for every signed-in test account, regardless of subscription variables. Research-service misconfiguration still fails visibly: full access removes the entitlement barrier, not evidence or infrastructure checks.

​

Where information comes from

Report V1 source lists provide notebook-level or strain-source-group provenance and do not prove that every generated sentence has its own citation. Report V2 implements four explicit fact classes, claim-level evidence, and absence-preserving validation. Its write path remains gated while those guarantees are certified for launch.

​

Updating a published notebook

The first-party update contract never edits a publication in place:

1. A future freshness policy detects reviewed research newer than the current publication.
2. The user explicitly chooses whether to generate a candidate.
3. The current notebook remains readable while the candidate runs.
4. Failure or cancellation leaves current unchanged and supports a deterministic retry state.
5. A validated candidate is atomically promoted, and the prior publication remains readable and comparable in history.

Notebook Studio exercises every state with synthetic data. The customer requestPublicationUpdate action is still hard-disabled until the research watermark and refresh policy are approved, so this section describes the validated contract rather than an enabled production action.

​

Verified retry behavior

Notebook sections have independent persisted state. If one fails, High IQ can retry the failed section while preserving completed sections. Companion artifacts have stable generation identities in the durable planning contract, including notebook source hash, profile, source readiness, recipe, media configuration, approved creative configuration, and executor-registry fingerprint. The transaction model can validate exact-latest failed retry, bounded scheduling reconciliation, cancellation events, supersession, and outdated state. There is no production claim/dispatch/reconciliation worker, safe owner artifact-cancel route, or Trigger run-cancel handshake. Those are launch blockers, and all execution remains inert while zero executors are selected.

​

Companion control-plane lifecycle

The status vocabulary above is durable control-plane behavior, not a claim that an executor currently produces every format or that every state is exposed in the customer app. The shared registry contains candidate definitions but zero selected executors, and the execution gate is hard false. A future executor must match its entire immutable registry record before install, claim, and callback. NotebookLM is absent from product execution contracts, task/build roots, and deployment roots. Historical decoders remain so old records can be interpreted, but their capability fields are redacted from customer reads.

​

Current launch gates

The staging system intentionally fails closed:

• Report V1 is classified as legacy-unvalidated for content-derived artifacts.
• Report V1 can synthesize fallback/default content and does not preserve source absence consistently. It must not be presented as guaranteeing that missing values stay unavailable.
• Stories, Daily Stories, mindmaps, audio scripts, audio, infographic specifications, and video storyboards require evidence-first Report V2 before production generation.
• Daily Story scheduling and generation are inert; there is no automatic daily account service.
• Generative images and video remain off until quality, commercial rights, privacy, regional, moderation, reliability, latency, and cost evaluations pass.
• Private artifact storage and evidence-first content safety must be certified before launch.

These gates let the team test multiple notebook profiles without implying that every proposed format is production-ready.

​

Related articles

• Notebooks Overview
• Notebook Stories
• Daily Stories
• What’s in Pro