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.
By the TidyX team · Updated
From estimated impact to actual outcome
Before execution, AI impact estimates are preliminary suggestions, not measured changes. After execution, the report uses 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 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 dictionaries can be downloaded separately, and successful runs can be saved as recipes. Usage & credits shows recorded quotes, reservations and settlements. A failed step releases its reservation; a successful earlier AI step remains charged.
Continue exploring