DECISION: [ADR-016] Quality Gates as Predicates
DATE: 2026-02-18
TYPE: 2 (reversible)
STATUS: Accepted
SOLITON SCORE: 0.82

## Context

Data quality must be validated before reaching the intelligence ring.
Bad data in a causal model produces bad causal estimates — garbage in,
garbage out, but with undeserved causal confidence.

## Options Considered

### Option A: Great Expectations-style declarative checks
Pros: Industry standard, rich ecosystem.
Cons: External dependency. Complex configuration.

### Option B: Pure function predicates (selected)
Pros: Each gate is a pure function: data -> pass/fail + details.
Composable, testable, auditable. Each gate logs to AuditLog.
Zero dependencies. Custom gates via simple callable.
Cons: Less feature-rich than Great Expectations.

### Option C: SQL-based checks
Pros: Familiar to data engineers.
Cons: Requires SQL engine. Overkill for list[dict] data.

## Decision

Quality gates are pure predicate functions implementing a common interface.
Built-in gates: completeness, bounds, type, uniqueness, freshness.
Custom gates via callable. All results logged to AuditLog.

## Rationale

Pure functions are the most testable and auditable form of validation.
Each gate can be unit tested independently. The pipeline composes gates
and provides aggregate pass/fail with detailed reporting. SR 11-7
requires documentation of data quality controls — the audit log
provides this automatically.

## Consequences

**Easier:** Testing, auditing, custom gate creation, pipeline composition.
**Harder:** No declarative YAML config (gates defined in code).
