SafeSeed: Fake by Design

A privacy incident doesn’t have to begin with someone proudly uploading production_customers.csv to GitHub and announcing it in Slack. It can begin with a copy.

A copy in staging. A copy in CI fixtures. A copy on a developer laptop. A copy in a bug ticket screenshot. A copy in that one shared drive folder called temp_final_REALLY_FINAL, because apparently every organization has to maintain a small haunted forest.

Everyone agrees on the sermon: do not use real personal data in non-production environments.

Lovely. Correct. Frequently useless.

Because the moment someone says “use synthetic data,” the real question is: synthetic how?

Some synthetic-data tooling learns the shape of your real data from your real data. That may be useful for analytics, simulation, or model training. But for privacy, it leaves you arguing about memorization, resemblance, linkage, re-identification, and whether the fake thing is still dragging a little production-data ghost behind it.

SafeSeed takes the boring, defensible path: its generator doesn’t use production records as source material.

The fields that look like personal data come from a versioned catalog: protocol-reserved domains and IP addresses, authority-designated fictitious or invalid values, published test numbers, and deliberately fake tokens. Documentation emails. Documentation IPs. Test card numbers. Fictitious phone ranges. Each field carries the claim its source supports.

Generated without a production dataset. That’s the claim to inspect.

Quick start

Four honesty tiers

Not all fake data is equally fake. Sounds obvious, until someone hands you “synthetic” records generated from production data and asks whether the privacy risk is gone. The risk is not gone. The risk is still in the room, standing in the corner, smiling smugly in his knockoff Ray-Bans.

SafeSeed labels each generated field with the strength of claim it actually earns.

Generate and verify a test CSV

Need a contact list for a staging demo? Start with SafeSeed’s CRM contacts preset. You’ll get a CSV of invented contacts and a JSON receipt that records the settings, field constraints, and file fingerprint. Open the generator, then follow these steps.

1. Choose a preset. CRM contacts starts with six columns. Marketing attribution, Hashed audience, and UK contacts provide other starting points.
2. Edit the columns. Change a column name or field type, remove a column, or choose + Add generated column. Use descriptive column labels; the generator doesn’t need customer records.
3. Set Rows and Seed. For a first run, leave Rows at 100 and Seed at 1. A seed is the number that makes generation repeatable: the same column names and types, row count, seed, and SafeSeed version produce the same CSV.
4. Select Generate. Review the column names and values in the preview before using the file in your test.
5. Download both files. Select Download CSV and Download receipt. The files are safeseed-data.csv and safeseed-data.receipt.json.
6. Check the pair. Select Edit columns, then Verify a file. Choose the CSV under SafeSeed CSV and its JSON file under Receipt, then select Verify. An unchanged generated pair returns Receipt matches. Select Verify another to check a different pair.

Generation and verification happen in your browser. The tool reads the selected CSV and receipt locally; it doesn’t upload their contents.

The browser checks the whole file. Editing a value or adding, removing, or reordering columns fails verification. If you need evidence of later changes, protect or review the original receipt separately from the CSV. Someone who can replace both can recompute both.

Wire it into CI/CD

For a checked-in test fixture, run verification as part of continuous integration (CI). A mismatch fails the step. Make the check required in your repository settings if you want it to block a merge. Review changes to the receipt as well as changes to the CSV; generating a fresh receipt for every change would defeat the drift check.

With Node.js 22 or later installed, create a fixtures folder in your project, then run:

# Generate a repeatable test fixture and its receipt
npx safeseed@0.4.1 generate --fields email:email,phone:phone,ssn:ssn,card:creditCard --rows 1000 --seed 1337 --out fixtures/seed.csv --record fixtures/seed.record.json

# Check the exact file against the reviewed receipt
npx safeseed@0.4.1 verify --in fixtures/seed.csv --record fixtures/seed.record.json

These examples pin SafeSeed 0.4.1. npx may download the package on first use; generation and verification run locally. Older SafeSeed receipt formats may be rejected, so regenerate the CSV and receipt together when migrating an old fixture.

In a GitHub Actions job that has already checked out the fixture and receipt, add this step. The current Action lives in AF Toolkit’s SafeSeed 0.4.1 release:

# Add under jobs.<job>.steps after your checkout step
- uses: advokat-frida/af-toolkit/safeseed@safeseed-v0.4.1
  with:
    data: fixtures/seed.csv
    record: fixtures/seed.record.json

The browser and Action both use strict whole-file verification. The Action runs the CLI bundled with that release; it doesn’t install another copy from npm.

Checking an existing CSV without a receipt is a different job. The CLI’s scan command checks the columns you name against catalog constraints. It doesn’t certify that a file contains no personal data. See the CLI examples for scanning and the explicit --allow-added-columns verification option.

What it proves, and what it doesn't

The one sentence to keep: “not derived from production data” is not the same claim as “not personal data.” SafeSeed’s generation path supports the first claim. Whether information relates to an identifiable person still depends on context; a green verification result doesn’t decide that question. GDPR Recital 26 sets the legal test, not the color of the button.

Where this fits your program

SafeSeed is a control for non-production test data. Not a privacy program. Not a compliance strategy. Not a blessed amulet you tape to a staging database while pretending access controls are someone else’s problem. A control. A useful one.

If your team has implemented the generation and CI check described above, here’s wording to adapt for a control register or privacy impact assessment:

We generate declared test-data fields through SafeSeed’s versioned catalog without using a production dataset as source material. We retain the CSV and an unsigned JSON receipt, review changes to the receipt, and run strict verification in CI to check the file’s content fingerprint, structure, and declared field values. This control can support our data-minimization and security measures for non-production environments. It doesn’t establish anonymity, authenticate origin, or replace access, retention, and deletion controls.

The usual caveat, stated plainly: this is a practitioner's mental model and a how-to, not legal advice. Your facts, your counsel.

Questions a skeptic asks first

Get SafeSeed

Start with the browser generator when you need a CSV and receipt without installing anything. SafeSeed is also a command-line tool, a JavaScript library, and a strict verify GitHub Action. The tool runs generation and verification locally because test data does not need to become SaaS confetti.

To add the library to a Node.js project, install the version used in the examples:

npm install safeseed@0.4.1

Or read the source, inspect the standards, and kick the tires on GitHub.

—🦊

Catch something wrong, or just want to argue with me? hello@advokatfrida.com