Skip to main content

Notebook Program

Notebooks are the center of the High IQ Pro value proposition. They turn a saved dispensary order or selected stash items into a reusable educational record with explicit source provenance, recoverable generation, and immutable versions.
High IQ is pre-launch. The first-party engine, local Studio, immutable publication model, and guarded research contracts are built in draft branches, but customer Report V2 writes, research-revision writes, update requests, companion executors, and automatic schedules remain disabled. Do not describe a gated capability as live.

Product promise

The launch promise is a readable, evidence-led notebook—not a bundle of unverified AI media. A launch-ready notebook must:
  • preserve every recorded order line, including unknown and ambiguous strain names;
  • distinguish recorded facts, research facts, and model synthesis;
  • show unavailable information instead of inventing a value;
  • continue safely when the user minimizes or closes progress UI;
  • preserve the last readable version during cancellation, failure, or an update;
  • publish a new immutable version only after validation;
  • retain prior validated versions for owner-only reading;
  • keep optional images, audio, video, stories, and diagrams independently gated.

Current system

The core composition engine is deterministic and provider-independent. Research and optional media providers sit behind typed boundaries; replacing a vendor must not change notebook ownership, source snapshots, evidence links, publication history, or lifecycle semantics.

Status snapshot

User journey

1

Import and review an order

The user imports an order through an available text, image, or connected-source path and reviews every recorded line before saving.
2

Resolve strain identity

Exact and approved alias matches attach a canonical strain. Ambiguous, placeholder, and unknown names remain explicit; the system does not attach the first search result.
3

Prepare research

Known subjects use available research. New or stale subjects enter a bounded research-readiness state. Queue acceptance is not treated as research completion.
4

Generate and monitor

The user starts the paid notebook. Progress can be minimized, dismissed for the attempt, reopened, or canceled. The server state—not an open sheet—owns the work.
5

Read and revisit

Validated lessons, evidence, source context, and unavailable states become a reusable learning record.
6

Choose future updates

New reviewed research can offer an update. The user compares changes and explicitly requests a new version. The current version remains readable until a validated candidate is atomically promoted.

Delivery stack

All links below are draft PRs. Do not merge or activate them without a separate review decision.

Non-negotiable boundaries

  • Do not reintroduce NotebookLM into any deployable customer runtime.
  • Do not enable a provider from a client flag or environment variable alone.
  • Do not apply the research migration before Plan 066 establishes the canonical database baseline and full pgTAP proof.
  • Do not wire live research engines until retry exhaustion, non-owning dispositions, the legacy catalog shortcut, and callback semantics are defined and tested.
  • Do not silently rewrite a published notebook when research changes.
  • Do not expose raw generation identifiers, provider payloads, personal source data, or operational lineage in historical content.
  • Do not promise companion media until its executor, evidence input, privacy, rights, safety, cost, cancellation, and retention gates pass.

What to do next

  1. Use Notebook Studio to review the complete product and edge-state matrix without the mobile app.
  2. Follow Research and generation when changing order matching, source readiness, evidence, or publication contracts.
  3. Follow the Launch runbook in order. Do not skip directly to migration or provider activation.
  4. Complete native-device certification before calling the paid notebook ready.