Contract batch and streaming results so they stop disagreeing silently

• Define whether the metric is final, provisional, or revisable and which clock governs business truth. Identify late-data horizon, correction policy, decision impact, and required reproducibility.

• Estimate event volume, out-of-order distribution, state size, nightly recomputation cost, and affected decisions. Watermarks should follow observed lateness rather than a convenient fixed interval.

• Batch and stream use one versioned semantic definition, outputs carry provenance and completeness, corrections are explicit, and consequential decisions remain reconstructable.

• Create a shared transformation specification and test fixtures, canonical immutable input log, versioned feature or metric store, stream processor for provisional results, and batch verifier that emits correction events rather than overwriting invisibly.

• Inputs carry event and ingestion times, source sequence, schema, and correction linkage. Outputs carry computation version, input watermark, confidence or finality, and superseded result ID.

• Use event-time windows with explicit late-data rules. Online readers choose the newest approved result under policy, while finance may wait for a closed watermark and later restatement workflow.

• Checkpoint streaming state, make corrections idempotent, and reconcile missing source ranges before declaring final. A bad computation version is disabled through policy while prior outputs remain available.

• Apply identical access and privacy transformations in both paths, and restrict retained raw input by purpose. Correction history is auditable without exposing sensitive feature values broadly.

• Measure batch-stream delta, late-event rate, watermark age, correction magnitude, version coverage, and decisions changed after correction. Alert on semantic drift even when both pipelines are healthy.

• Share source and semantic assets but allow optimized execution engines. Incremental batch verification and targeted recompute reduce cost compared with rewriting the full online store nightly.

• A single engine reduces implementation drift but may fit one workload poorly. A shared semantic contract plus parity tests allows two engines while making disagreement observable and governed.

• Version transformations, dual-compute on identical inputs, compare by cohort, and switch reader policy only after parity thresholds. Backfill new versions without erasing prior decision evidence.

• Principal candidates define finality and correction semantics, not just Lambda versus Kappa architecture. They make disagreement a measurable contract and protect downstream decisions from silent overwrite.

Interviewer evaluation rubric