# Data Pipeline & Quality 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 batch/stream/ELT/notebook pipeline across lineage, contracts, quality, retries, late data, reproducibility, and operational ownership.

## Domain invariants

- Source-to-sink lineage, schema, identity, partition/window, watermark, units, nullability, and ownership are explicit.
- Retries, partial batches, late/out-of-order data, duplicates, schema evolution, and backfills converge deterministically.
- Quality checks detect completeness, validity, uniqueness, referential, distribution, and freshness failures at useful boundaries.
- Notebooks and ad-hoc logic are promoted to versioned, testable pipeline code before they own production behavior.

## Audit method

1. Trace one dataset from source extraction through transforms, storage, quality gates, consumers, and backfill path.
2. Check checkpoint/offset ownership, partition overwrite/append semantics, duplicate/late data, partial commit, and retry/resume.
3. Inspect schema contracts, lineage metadata, data tests, alerts, quarantine, reconciliation, and privacy/retention.
4. Identify hidden notebook/manual steps and environment/dependency drift.

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