Coming soon
Reusable cleaning recipes need more than a saved prompt
A reliable recipe should freeze supported rules, identify the schema it was designed for, and stop when a new file no longer matches. The recipe experience is available for development review, while persistence and execution remain clearly deferred.
What a versioned recipe is meant to preserve
The planned recipe model groups an immutable rule version with its expected columns, types, dictionary notes, safeguards, and provenance. Editing rules creates a new version instead of rewriting the historical recipe used by an earlier run.
This design keeps reuse explainable. A user should be able to see which version was selected, what changed between versions, and which frozen snapshot was ultimately confirmed for a run.
Schema drift must interrupt automatic reuse
Before a future recipe can run on a new file, the service will compare required columns and expected types. Missing fields, renamed columns, new columns, empty required fields, and invalid rule targets must become visible drift states rather than silent guesses.
Exact matches may proceed to review. Compatible changes can be acknowledged. Blocking drift requires a deliberate mapping or a revised recipe version. The current Worker never receives preview-only mappings or unsupported advanced rules.
- Exact, compatible, warning, and blocking outcomes
- Explicit source-to-target column mapping
- Unmatched categories remain visible
- No automatic execution after a preview match
Why this page says coming soon
Recipe cards, versions, drift, and mapping are currently fixtures inside the development-only preview. They do not create database rows, save user data, call an AI mapping service, or send a plan to the Worker.
The real product continues to support creating and running a plan for the current project. Public pages describe recipe reuse as planned until repository, ownership, audit, and backend validation contracts are implemented.