---
title: Problem Being Solved
product: ebcprep-orchestrator
doc_type: concept
version: main
source: git2docs (code-derived, validation-filtered)
canonical: https://git2docs.com/jan-mark-holzer/docs/ebcprep-orchestrator/ebcprep/problem-statement
---

# Problem Being Solved

_Making terminal output colorful and styled_

## Overview

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.

## Content

## 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.

## Related concepts

- **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.