Auditable results
A data cleaning report should describe the run that actually happened
A plan is an intention; a report is evidence. After deterministic execution, the report center uses stored run data to show measured changes and provenance without filling missing fields with mock audit values.
From estimated impact to actual outcome
Before execution, an impact preview can help you understand the likely effect of confirmed rules. After execution, the report switches to the Worker summary: rows in and out, columns in and out, cells changed, rows removed, per-rule results, rows flagged, failed values, and warnings when those values are present.
The distinction prevents a preliminary estimate from being presented as a completed result. Failed runs show a safe error and preserve the original upload. A retry creates another attempt in run history rather than rewriting a successful record.
Provenance that comes from the stored run
The real report displays the rules-engine version, rule snapshot SHA-256, input SHA-256, output SHA-256, and completion time when those fields exist. These values tie the visible summary to a specific execution attempt and output.
The confirmed plan is immutable for the run. That makes it possible to compare the frozen snapshot with the reported outcome without relying on an editable UI state.
- Actual rule results from summary JSON
- Frozen rule snapshot hash
- Input and output hashes
- Engine version and timestamps
Current downloads and planned report modules
A successful run provides the one cleaned format selected for that run, plus a PDF report and JSON audit. Signed cleaned-file links are short lived. Source generators for Python and R remain in the repository, but they are not exposed in the current product interface.
Data dictionary versions, recipe exports, credit charges, and richer lifecycle events appear only in the development preview until real backing data exists. Public copy does not claim that those artifacts have already been saved or generated.