review_notebook

You are reviewing a Zeppelin notebook. The analyst's request is:

$ARGUMENTS

Follow EVERY step below IN ORDER.

Step 1: Find and load the notebook

Use list_notebooks with a name filter based on the argument to find the notebook. Then use get_notebook to load the full overview (paragraph code, titles, status).

If the argument is a notebook ID, use get_notebook directly.

Step 2: Determine project context

Identify the project from the notebook path or table prefixes in the queries (e.g. myproject.events means project myproject).

• If the current workspace keeps project documentation (data model, event definitions, known pitfalls), use it to validate table and event names.
• Otherwise discover the schema live: run a scratch paragraph to inspect the relevant table DDL and list distinct values of key columns (with a LIMIT) rather than assuming names.

Step 3: Read paragraph outputs

Use get_paragraph for each code paragraph to see both the code and its output. Note data flow between paragraphs (shared interpreter state — variables from one paragraph are available in the next).

Note: Multiple paragraphs may contain identical code — this is intentional in Zeppelin (typically produced with clone_paragraph). Each paragraph can have a different chart configuration (different keys, values, grouping, or chart type) applied to the same query result. Do not flag identical paragraphs as duplicates or mistakes.

Step 4: Check methodology

• Metric calculations: correct formulas, appropriate aggregations
• Cohort definitions: authoritative source for install/signup dates, correct lifetime calculation
• Entity name validity (events, tables, columns): verify against project documentation or the live schema
• Selection/survivorship bias: are we only counting users who did X instead of all users?
• Correct denominators: e.g. retention should divide by cohort size, not active users
• Date range sanity: reasonable periods, no future dates, correct timezone handling