Cleaning Up Demo Data? Preview What You’ll Archive

Imagine a maker marketplace that launched with ten sample listings. The owner later turned one of them into a real offer by replacing the photos, changing the price and taking an order against it. Weeks later, an AI assistant proposes a bulk cleanup: archive everything that came from the original sample set. The rule sounds precise. It would still take a working listing out of the shop.

The mistake is treating a record’s origin as its current purpose. A sample can stay a sample, become a template for legitimate work or end up attached to a real transaction. Before a cleanup changes anything, ask for a list of exactly what will be affected and why each record qualifies. The approval should apply to that selection, rather than to a vague instruction to tidy up.

Separate origin from what the record does today

Start with the strongest evidence you have about where each example came from: an installation manifest, an import log or stable IDs from the original sample set. A familiar seller name or a price that looks wrong is a clue for review, but real records can share both. Conversely, a sample can acquire a new name and still be a sample. If you cannot establish the origin confidently, put the record in a review list instead of treating a guess as a removal rule.

Then check how the record is used now. In the fictional marketplace, a live order linked to a listing is a reason to leave it out of the automatic selection and investigate. A changed photo might warrant inspection without settling the question. You may also have a useful reference record, such as a category or shipping template, that was installed at the same time as the examples. Decide what each type of record is for before you group it with the clutter.

Keep future experiments separate where possible. Stripe’s testing documentation, for example, explains that sandboxes can simulate payments without moving real money. That is a payment environment boundary. It does not establish that your own application database, public catalogue or reporting system separates test records. Check each of those paths yourself before assuming the word ‘sandbox’ covers them.

Approve the exact list, then check what actually changed

Give the reviewer a preview with a stable record ID, recognisable title, current status and a short reason for including each item. Show records held back for review separately, with the reason they were held. A count of nine records is useful for orientation; it cannot tell you whether the nine include the right ones.

A preview can also go stale. If a listing is edited or receives a real order between review and execution, stop and check it again. Ask the developer how the job handles a record whose status or relevant links changed after approval. A practical answer is to skip that record and report why, or to stop the batch for a new review. Either policy is clearer than quietly applying yesterday’s decision to today’s catalogue.

Ask for a result you can reconcile with the preview. The PostgreSQL 17 documentation on RETURNING describes a way for supported write statements to report the rows they changed. You do not need PostgreSQL to adopt the principle: record the IDs actually changed and compare them with the approved IDs. The PostgreSQL transaction tutorial also explains how a rollback can cancel updates before commit. That is different from restoring a record after a completed cleanup. If you want that option, plan an archive state and a way to restore the previous state after the job finishes.

Keep the preview and the outcome together as one record of the cleanup. Include who approved it, the date and the original status of each item that changed. If a restored item has since been edited, review that newer work before replacing anything. A restore should recover the intended listing without automatically undoing unrelated changes someone made afterwards.

Follow a sample record through the whole business

A listing disappearing from an admin view is only one check. Decide where archived examples should stop appearing: public search, product recommendations, exports and operational totals might each use a different query. An archived item can remain in an internal history for legitimate reasons. The rule should explain why it remains there and why it no longer counts as live activity. Our guide to tracing AI-built dashboard figures to real records covers the counting side of that work.

• An untouched example: It appears in the preview, is archived and disappears from public browsing and active listing totals.
• A converted listing: It stays live, with its linked order and current settings intact.
• A changed record: Modify a candidate after the preview. The job reports the change and leaves it alone until it is reviewed again.
• A mistaken archive: Restore one example in a test environment and verify that its prior state and links return as expected.

Run the check with a small batch first. Save enough of the before and after state for someone who did not run the job to explain the outcome. If archived entries vanish from search but still inflate a sales report, finish that part of the work before calling the cleanup complete. The goal is a shop whose records tell the truth about what is for sale and what has actually happened.

Sources

• Stripe, Testing use cases, on sandbox behaviour.
• PostgreSQL 17 documentation, Returning data from modified rows and Transactions.