Problem Being Solved

This page explains the core problem that ebcprep was built to solve: the manual, repetitive work of keeping executive prep notebooks current as meetings are added and updated. Understanding this problem will help you recognize which parts of ebcprep's design are intentional trade-offs and why the tool works the way it does.

The manual workflow EBC teams face

When an Executive Briefing Center team manages dozens of upcoming meetings across multiple executives, the coordination work quickly becomes significant. For each meeting added to the tracking spreadsheet, someone on the team typically has to:

1. Open NotebookLM and create (or locate) the right executive's notebook.
2. Find the prep Google Doc for that meeting and paste its URL into the notebook as a new source.
3. Rename the source to something readable — otherwise it inherits whatever title the Google Doc has, which is rarely consistent.
4. Share the notebook with the executive, their EA, their Chief of Staff, and any always-included support staff.

With five executives and ten meetings each, that's fifty sources to add, fifty renames, and potentially hundreds of share invitations — before the first meeting happens. Then new meetings land every week and the cycle repeats.

Why spreadsheets alone don't solve it

The feeder spreadsheet is a natural place to track meetings because it's easy to update and share. But a spreadsheet has no way to reach into NotebookLM and act on what it contains. The gap between "the row exists in the sheet" and "the source exists in the notebook" has to be closed by a human doing manual copy-paste work, or by automation.

The automation gap is exactly what ebcprep fills. It reads the feeder spreadsheet on every run and reconciles its rows against what already exists in NotebookLM, creating notebooks, adding sources, and sending invites only for the work that hasn't been done yet.

The deduplication problem

Automatic sync creates a secondary problem: how does the tool avoid duplicating work on re-runs? If a sync adds a source and then the tool runs again, it needs to know that source is already there. ebcprep solves this with a content hash — a fingerprint computed from the executive's name and the prep-doc URL for each row. This hash is stored in the local state database (data/ebcprep.db) after each row is processed. On subsequent runs, any row whose hash is already in the database is silently skipped. This means re-running ebcprep sync is always safe: it never adds a source twice, never sends a duplicate invite, and never overwrites a notebook that already exists.

Why a local CLI, not a server

ebcprep runs entirely from your laptop. There is no server to deploy, no scheduler to configure, and no cloud service to manage. This is a deliberate trade-off: the tool is designed to be operated by an EBC team member who already has the right Google access, runs it on demand (or on a schedule from their own machine), and keeps the state database on local disk. This keeps the operational footprint minimal — no infrastructure to maintain, no credentials to rotate in a remote environment.

What ebcprep does not do

ebcprep does not write back to the feeder spreadsheet. It does not modify your Google Docs. It does not delete notebooks or sources when rows are removed from the sheet. Its job is purely additive: read the sheet, create what is missing, skip what already exists.

Seeing the problem in action: a dry run before the first real sync

Before running a full sync, you can preview exactly what work is outstanding. This is most useful the first time, when no notebooks exist yet and the gap between the sheet and NotebookLM is largest.

ebcprep sync --dry-run

Expected output (abbreviated):

[DRY RUN] Jane Doe
  → Would create notebook: Executive Prep — Jane Doe
  → Would add source: Acme Inc. — 05/11/2026 9:00 AM–09:30 AM
  → Would add source: Globex Corp. — 05/14/2026 2:00 PM–02:45 PM
  → Would invite: jane.doe@example.com
  → Would invite: ea-name@example.com (EA)

[DRY RUN] Brian Stevens
  → Would create notebook: Executive Prep — Brian Stevens
  → Would add source: Initech — 05/12/2026 10:00 AM–10:30 AM
  → Would invite: brian.stevens@example.com

Dry-run complete. 2 notebooks, 3 sources, 3 invites would be created.

Nothing is changed in NotebookLM during a dry run. Use this to verify the sheet is set up correctly before committing to a full run that may take one to two hours.

Running the real sync after confirming the preview looks correct

ebcprep sync

Expected output (abbreviated):

Jane Doe
  ✓ Notebook created: Executive Prep — Jane Doe
  ✓ Source added: Acme Inc. — 05/11/2026 9:00 AM–09:30 AM
  ✓ Source added: Globex Corp. — 05/14/2026 2:00 PM–02:45 PM
  ✓ Invited: jane.doe@example.com
  ✓ Invited: ea-name@example.com (EA)

Brian Stevens
  ✓ Notebook created: Executive Prep — Brian Stevens
  ✓ Source added: Initech — 05/12/2026 10:00 AM–10:30 AM
  ✓ Invited: brian.stevens@example.com

Sync complete. 2 notebooks created, 3 sources added, 3 invites sent.

Running sync again after new meetings are added — deduplication in action

After adding two new rows to the feeder sheet for Jane Doe, re-running sync only processes the new rows:

ebcprep sync

Jane Doe
  – Skipped (already processed): Acme Inc. — 05/11/2026 9:00 AM–09:30 AM
  – Skipped (already processed): Globex Corp. — 05/14/2026 2:00 PM–02:45 PM
  ✓ Source added: Umbrella Corp. — 05/20/2026 11:00 AM–11:30 AM
  ✓ Source added: Initech — 05/21/2026 3:00 PM–03:30 PM

Brian Stevens
  – No new rows.

Sync complete. 0 notebooks created, 2 sources added, 0 invites sent.

Already-processed rows are detected via their stored content hash and skipped instantly, so only the genuinely new work triggers API calls.

• Configuring ebcprep — how to set up the .env configuration file and service account so ebcprep can read your feeder spreadsheet.
• Preparing the feeder spreadsheet — the required column layout and what values cause a row to be skipped.
• Running a sync — step-by-step instructions for previewing and executing a full sync run.
• Keeping notebooks current — how to handle the ongoing workflow as new meetings are added each week.
• State database (ebcprep.db) — how the local SQLite file tracks completed work and what happens if you delete it.
• defaults.toml — how to configure always-included collaborators and default sources that appear in every notebook.