01What this edition can substantiate
| Evidence type | What it supports | What it does not establish |
|---|---|---|
| Source inspection | The topology, SQL definitions and configuration described in this guide | Successful execution on every machine or connector compatibility under every workload |
| Saved static contract checks | Eight configuration assertions and the source-file hashes recorded in the verification artifact | Live pipeline health, SQL execution or data accuracy |
| Guided expected observations | A reproducible procedure and the intended interpretation | A measured result from a real run |
| Runtime experiment records | Only the outputs, environment and assertions explicitly captured for that run | Universal exactly-once, performance or production readiness |
02Historical runtime evidence
The original repository contained scripts and guides, but no committed runtime result bundle that establishes a past successful end-to-end run. Therefore the public lesson text does not turn the old README’s expected behavior into measured results.
Publication verification is a separate artifact. Inspect its scope, status and timestamp. A successful page build, link check or shell test is evidence about the published project; it is not a replacement for running the data pipeline.
The current saved record reports eight static checks passed and runtime_tested = false because the Docker daemon was unavailable. The SQL version fix was inspected statically, not exercised against a live Flink job.
03Make your next run inspectable
- Record the source commit, image tags, operating system, CPU architecture, Docker resources and time zone.
- Save the command, exit status, start/end times and the smallest output needed to support each claim.
- For a data check, record order IDs, query text, query time, both lake counts and audit time. Use a fixed cohort for deeper comparisons.
- For recovery, record the failed component, job state transitions, last completed checkpoint and checked records after restart.
- Keep raw logs and configuration local. Before sharing, remove credentials, personal paths, internal addresses and unrelated records.
- Label outcomes pass, fail or not run. Keep unexpected results and explain the unresolved uncertainty.
04Known limits worth testing
- The producer is random and continuous; it does not generate an identical fixture on every run.
- The count audit has no common snapshot or field-level checksum. Equal counts are a weak consistency signal.
- Join state expires after its configured TTL; no explicit event-time late-data policy is implemented.
- ClickHouse ingestion has no row-deletion mapping for Kafka tombstones. TTL cleanup is not equivalent to source-delete propagation.
- The revised wide-table version includes order, payment and dimension timestamps at millisecond precision. Same-millisecond updates and inconsistent source clocks can still tie or misorder versions; this is not a transaction sequence.
- Iceberg uses a local shared filesystem catalog; no scheduled snapshot expiration or complete seven-day disk-retention guarantee is provided.
- The cluster is single-machine without JobManager high availability. A task restart exercise and a full cluster restart test different recovery boundaries.
05Choose conclusions proportional to the evidence
Good: “For these recorded order IDs, the source and FINAL serving query matched after recovery.” Stronger: “For this fixed cohort at this cutoff, key and selected-field comparisons passed.”
Too broad: “The whole pipeline is exactly-once,” “Paimon is faster than Iceberg,” or “all data is deleted after seven days,” based only on a green dashboard or a count delta of zero.