---
title: Intended Audience
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/intended-audience
---

# Intended Audience

_CLI tool authors and terminal application developers_

## Overview

This page describes who ebcprep is built for and what background you need to use it effectively. Understanding the intended audience helps you set the right expectations — both for the complexity of the tool itself and for the external systems it integrates with.

## Content

## Who ebcprep is for

ebcprep is designed for **platform engineers and SREs** who are comfortable in a terminal and familiar with managing service credentials, environment variables, and configuration files. You do not need to be a Python developer or understand ebcprep's internals to operate it — the CLI surface is intentionally small and the configuration is declarative.

You will, however, need to be comfortable with the following:

- Running commands in a shell and reading their output
- Creating and managing a GCP service account JSON key
- Editing `.env` and `.toml` configuration files
- Understanding the difference between a dry run and a live run before executing writes

## What you are responsible for

ebcprep is a **CLI tool**, not a managed service. It runs on your laptop, stores its state in a local SQLite file (`data/ebcprep.db`), and has no server component. That means you are responsible for:

- **Keeping the feeder spreadsheet accurate.** ebcprep reads the Google Sheet on every sync and trusts it as the source of truth. If a row is wrong, the resulting notebook will reflect that.
- **Re-authenticating NotebookLM periodically.** The session saved by `nlm login` expires every few weeks. When it does, you run `nlm login --profile <name>` again before syncing.
- **Running syncs when needed.** ebcprep does not run on a schedule. You invoke `ebcprep sync` whenever new meeting rows have been added to the sheet.

## What you do not need to know

ebcprep deliberately hides the complexity of interacting with NotebookLM's internal APIs. You do not need to understand how notebooks are created or how sources are named — the tool handles all of that. You also do not need to manage deduplication manually: the state database tracks every processed meeting by a content hash, so re-running `ebcprep sync` after a partial failure or a new batch of rows is always safe.

## Operator vs. executive

There are two kinds of people in an ebcprep workflow:

| Role | Description |
|---|---|
| **Operator** | The platform engineer or SRE who runs ebcprep. Owns the Google account that holds all notebooks and the GCP service account that reads the feeder sheet. |
| **Executive** | The person whose meetings are being prepped. Receives a share invite to their notebook and interacts with NotebookLM directly — they never touch ebcprep. |

This distinction matters because all notebooks are owned by a single operator account. Executives are added as collaborators via NotebookLM's share mechanism; they do not need to know how the notebooks were created.

## Skill level assumed

ebcprep is an **intermediate-level** tool. The quickstart is short, but the underlying ecosystem — GCP service accounts, NotebookLM session management, Google Sheets column layout — assumes you have seen these concepts before. If you are setting up the tool for the first time, run `ebcprep doctor` after configuration to validate all connectivity before attempting a sync.

## Related concepts

- **Install and authenticate** — step-by-step setup for operators new to ebcprep, covering `uv`, `nlm login`, and service account configuration.
- **Configure the tool** — how to populate the `.env` configuration file and the optional `defaults.toml` with always-included collaborators and default sources.
- **Prepare the feeder spreadsheet** — the required column layout for the Google Sheet that ebcprep reads on every sync.
- **Preview and run a sync** — how to use `--dry-run` to inspect planned changes before writing to NotebookLM.
- **Check sync status and inspect executives** — using `ebcprep status` and `ebcprep execs` to understand what the state database has recorded.