Reproducibility
AI suggestions can lead to reproducible cleaning when execution is separated
A model response alone is not a reproducible data pipeline. Reproducibility comes from validating suggestions, freezing the accepted rules, and applying them with a known deterministic engine to a known input.
Freeze the plan before execution
The AI returns structured suggestions, but the server rejects unknown operations, invalid parameters, unsafe targets, excessive rule counts, and free-form payloads. The user can then accept, skip, or edit only supported controls.
Confirmation makes the plan immutable. Starting a run creates a separate frozen snapshot of enabled rules and a SHA-256 value for that snapshot. Later UI edits cannot silently change the plan behind an existing run.
Record the input, output, and engine identity
A successful run can report its input hash, output hash, rule snapshot hash, engine version, timestamps, and actual summary. Together these values establish which source, instructions, and engine produced the result.
The PDF and JSON audit downloads expose run information in portable form. The selected cleaned format is the data artifact. Generator source for additional scripts remains internal in this phase and is not advertised as a current UI export.
- Validated rule DSL
- Immutable confirmed plan
- Frozen run snapshot and hash
- Recorded engine version and file hashes
What is not yet reproducible across projects
The current real workflow creates a plan for one project. Persistent, versioned recipes and schema drift mapping are still preview-only, so the product does not claim that a saved recipe can already be applied to a new file.
That future workflow will need immutable versions, ownership controls, schema fingerprints, blocking drift states, and explicit mappings before it can extend reproducibility safely across datasets.