Why plant rows the current product can no longer create into a manufactured test dataset?

The most dangerous thing a manufactured dataset does is agree with the code that generated it. ## What a generated dataset quietly assumes Generation rules describe the fields the current writers set, the enumerated values current validation allows, and the combinations the current flows can reach. That makes the dataset an unexamined claim: **every row in the real store was written by the code that is running now.** A store that has been in service for any length of time is sedimentary instead. It holds rows written by three versions of the writer, rows a migration touched and rows the same migration skipped, rows a support engineer corrected by hand at two in the morning, and rows that were perfectly legal under a rule tightened two years ago. None of those can be produced by today's write paths, and all of them are read by today's read paths. ## Where the residue comes from | Origin | The shape it leaves behind | What still reads it | |---|---|---| | A feature that was removed | a field only that feature ever set, or never set | listings, exports, any read older than the removal | | A back-fill migration | rows the back-fill skipped, failed on, or never saw | anything assuming the column is now always populated | | A manual correction | a value no validation would accept, a state reached out of order | state machines, reconciliation, audit views | | A validation rule that was tightened | values legal under the old rule, rejected by the new one | validation on read, re-save flows, bulk edits | | A bulk import | lengths, encodings and precisions the interactive path never produces | display, search, comparison | | A partial cleanup | a child row whose parent record was removed | joins, cascade handling, totals | The common thread is that these are all **read-path defects**. Nothing fails while the row sits there. Something fails when the product is asked to display it, total it, export it, or migrate it again. And a read-path defect found in production is expensive precisely because the row cannot be re-created — you cannot reproduce the bug by using the product, which is why it is often filed as unreproducible and closed. ## Finding the shapes without copying the data 1. **Profile, do not extract.** Run shape queries over the live store that count rows by whether a field is populated, by enumerated value, by combination, and by length band. What comes back is a table of shapes and counts, holding no personal data. 2. **Compare against what today's writers can emit.** For each shape, ask whether any current write path could produce it. Where the answer is no, the shape is residue, and its count tells you how much of it is still out there. 3. **Author a representative.** Write one row that has that shape, with invented values. It is manufactured data describing a real shape, not a copy of a real row, so nothing leaves the production boundary. 4. **Record why it exists.** A one-line note beside the label — "written by the withdrawn regional pricing flow, roughly forty thousand rows still present" — is what lets a future reader decide whether the row still earns its place. ## Then decide what a failure on one means The point of carrying these rows is that a test will eventually fail on one, and there are exactly two honest responses. Choosing between them is the judgement this subject is really about. - **The shape still exists in the live store.** The failure is a genuine defect. Real users, or a nightly job, will hit it. Fix the code; the planted row stays. - **The shape no longer exists** because a cleanup ran or the last rows were finally migrated. The planted row now describes a past that is gone. Delete it and record the date and the reason. This is the only legitimate way such a row leaves the dataset. What must not happen is the third option people reach for under deadline: deleting the row because it is inconvenient, without asking which situation applies. That converts a known defect into an unknown one and silently restores the assumption the planted row existed to break. ## How much of it to carry Not every residue shape earns a permanent row. Rank them by how many rows of that shape survive and how many read paths touch them. A shape with four rows left that no current screen displays is a better candidate for cleaning out of the live store than for planting — a shape removed from production is a shape nobody has to carry in the dataset forever. A shape with hundreds of thousands of rows is not going anywhere, and belongs in the manufactured dataset until it does.