OPS-CAT-001 — Make DQ initialization observable and durable
| Field | Value |
|---|---|
| Status | Open finding; deployed failure observed on 2 September 2026 |
| Severity | Critical |
| Affected surface | Data-quality initialization, watcher readiness, and Catalog Quality |
| Implementation issue | platform-stacks #672 |
| Code-change repository | sparqd/platform-stacks |
Where the problem appears
Inspect DQ initialization and watcher health for realm gj76anadpsc, workspace w-t5e2kcxjd, then open a table's Quality view.
Concrete observed case
The watcher remained Kubernetes Ready while reporting no usable DQ tables, rejecting a seeded table identity, and waiting for initialization. The completed initialization Job and its logs expired, removing evidence needed to diagnose the failed state.
Expected condition
Initialization validates schemas, Delta files, seed rows, and the same authenticated Trino read path used at runtime. Readiness stays false until the contract passes, evidence is retained, and reruns are idempotent.
Cause and evidence
- The running watcher reported zero discovered tables and continued waiting for initialization.
- Its readiness did not represent application readiness.
- The initialization Job was deleted before the failure could be reconstructed.
Why it matters
The deployment can report healthy while Catalog Quality is unavailable, and operators lose the evidence required to distinguish configuration, storage, identity, and initialization failures.
Existing controls and workarounds
Treat DQ as unavailable until direct contract checks pass. Pod Ready alone is not evidence of functional readiness.
Alternatives considered
- Recommended: contract-based readiness plus retained initialization status and logs.
- Keep the Job indefinitely — preserves evidence but does not make readiness accurate.
- Rely on watcher logs only — rejected because logs can expire and readiness remains misleading.
Component involvement
- Platform deployment owns initialization lifecycle and observability.
- DQ service owns canonical identifiers and runtime contract checks.
- Catalog consumes an explicit available/degraded state.
Reproduction and verification
Follow CAT-S021. Record the visible state, request outcome, effective identity, and recovery behavior relevant to this finding.
Resolution conditions
Close after clean initialization, authenticated reads, watcher restart, idempotent rerun, failure retention, and readiness transitions all pass.
Validation and blockers
Platform and DQ owners must validate. The current deployed result remains failed.