skills/vibe-domain/references/notebook-productionization-audit.md

# Notebook Productionization Audit

## Operation

Inspect the named boundary and report supported findings. Do not edit product code. Include concrete evidence, impact, the owning source, one remediation direction and a meaningful validation route. Severity follows actual impact, not a category example.

## Goal and scope

Audit a notebook or exploratory analysis before it becomes a repeatable pipeline, service, report, or decision artifact.

## Domain invariants

- Inputs, queries/snapshots, schema, credentials, privacy constraints, outputs, and consumers have explicit ownership and lineage.
- Execution does not depend on cell order, hidden kernel state, manual edits, local absolute paths, mutable remote data, or untracked packages.
- Parameters, randomness, time boundaries, timezone, sampling, and environment are explicit and reproducible.
- Exploratory visualization/commentary is separated from production transformations and decision-critical calculations.
- Production-owning logic has unit/data-contract/integration tests, bounded memory/compute, restart/idempotency, and observable failure behavior.
- Published artifacts preserve code/data/environment identity and do not expose secrets, personal data, or misleading stale outputs.

## Audit method

1. Execute from a clean kernel/environment in declared order and record every input, dependency, side effect, output, and manual intervention.
2. Trace data lineage and inspect mutable queries/files, schema assumptions, leakage, missingness, timezone, and sampling boundaries.
3. Identify reusable transformations versus exploratory cells and locate the correct package/pipeline/service owner.
4. Profile representative data volume, memory, runtime, retries, partial outputs, and restart behavior.
5. Review tests, dependency lock, parameter contract, scheduler/publication path, privacy, retention, and documentation.

## Priority model

- **P0:** cross-tenant access, incorrect billing/entitlement, corrupted canonical data, or decision-critical analytical error.
- **P1:** a material business-rule, data-quality, experiment, or analytics defect.
- **P2:** a lower-risk but concrete lineage, instrumentation, reproducibility, or maintainability issue.