What must be stripped from a production record before it goes into a drafting prompt, and what must survive?

## Why a real record is tempting in the first place Nobody reaches for production data purely out of laziness. A real record carries information no one invents: the field that is always present in the schema and empty in four rows out of ten, the surname longer than the column the interface reserved for it, the amount that arrives negative because a refund was posted against it, the locale that formats decimals with a comma, the identifier that is a run of digits and must never be parsed as a number. A case drafted from a real record exercises those. A case drafted from an imagined record exercises a tidy world that does not exist. **The value of the record is its shape, and its shape is not the part you have to protect.** That is the whole insight this leaf turns on. Redaction is not a tax on usefulness; done properly it removes only the part that was never useful. ## What must never enter the context Two categories, and they fail in different ways. - **Identity.** Names, addresses, contact details, dates of birth, account and card numbers, device identifiers, and free-text fields where people write about themselves. The moment this enters a prompt it has left your controlled systems: it may be retained, it may be read by colleagues with no basis to see it, it may cross a border, and it now sits somewhere your data inventory does not describe. Whether that processing was lawful is decided by the nature of the record, not by the tool's promises. - **Credentials.** Tokens, keys, session identifiers, signed links and one-time codes still inside their validity window. These do not merely describe; they *grant*. A shortened credential is not a safe credential - a prefix frequently identifies the issuing system and the holder, and truncation is not redaction. Free-text is where careful teams still get caught. A `notes` field on a support record is one person writing an unstructured paragraph about another person, and no field-level rule catches it. ## What has to survive | Property worth keeping | Why a draft needs it | Cheap substitute | |---|---|---| | Full field set, empty optionals included | Empty optionals are the edge a draft otherwise skips | Keep the key, empty the value | | Format and length | Truncation and validation defects live here | Same length, same alphabet, invented | | Encoding and script | Characters outside the plain alphabet break collation and display | A name in the same script | | Cardinality | One line item and two hundred are different cases | Keep the count, change the contents | | Boundary and awkward values | Negative, zero, maximum, already expired | Keep the value; it identifies nobody | | Relationships | A record with three linked accounts drafts differently | Keep the arity | Read the right-hand column as the technique in one word: **substitute, do not delete.** Deleting a field makes production look tidier than it is. Replacing every value with `xxx` erases exactly the properties that made the record worth having. Both produce a sample that teaches a drafting model about a system nobody operates. ## Make the safe path the convenient one Hand redaction is a control that depends on care under time pressure, which means it fails eventually. The durable version is to produce the sample set once, deliberately: 1. Take an extract inside the boundary where the data is already permitted to live. 2. Substitute identity and credential fields with generated values of the same shape, using a consistent mapping so relationships between records survive. 3. Have a second person check a sample of the output, looking hardest at free-text fields. 4. Store the result, versioned, where anyone drafting can reach it in a single step. 5. Refresh it on a schedule, because production shape drifts and a two-year-old sample teaches yesterday's edges. Now the compliant artefact is also the fastest one to reach for, which is the only arrangement that survives contact with a deadline. ## The two ways this goes wrong The obvious failure is under-redaction: a live record pasted in because it was already in a window and the request was urgent. The controls are the ordinary ones - training, a place to get safe samples, and honesty that a retention promise is one layer of defence rather than the whole answer. The quieter failure is over-redaction, and it is never reported as a failure. Every string becomes `test`, every amount becomes `100`, every name becomes `User One`, and the drafts that come back cover the happy path and nothing else. Because the record was safe and the process was followed, nobody logs a problem; the suite simply stops finding anything interesting. So when you review a sample set, ask what the ugliest value in it is. If there is no ugly value, the redaction removed more than it needed to.