The night after tape-out has a ritual. Someone opens the scratch tree for the project, sorts it by size, and starts deleting. Regression logs from March. Waveform dumps from a corner run that passed. Checkpoints from a netlist that was superseded three revisions ago. By morning, the project directory is 40% smaller and the storage team has stopped sending emails.

That ritual made sense for 30 years, and it stopped making sense the moment your company decided to train artificial intelligence (AI) models on its own design history.

Regression data retention is the practice of deciding which simulation runs, logs, and intermediate outputs survive a project’s close, based on what they can still teach rather than on how much space they take. It is a new discipline for electronic design automation (EDA) teams, because until recently the answer to “what do we keep” was “the deliverables,” and everything else was scratch. EDA data retention starts where that answer stops.

The purge was rational. The reason for it is gone.

Scratch data got deleted because it was expensive to keep and useless once the chip shipped. Both halves of that were true. A regression suite for a large block generates terabytes per pass, most of it waveform and log output that exists to answer one question, did this run pass, and has no purpose after that. Deleting it was good engineering.

Simon Rance of Keysight EDA described the shift in Semiconductor Engineering in March 2026: simulation runs and test results were thrown out, and now they need to be kept for machine learning. In a Keysight post two months later he went further. “A simulation run that used to be thrown away may now help train a model. A test result may help correlate design intent with real-world behavior.”

What changed is that the failed runs became the valuable ones. A model that predicts timing closure, coverage convergence, or where a placement will fail needs to see the runs that went wrong, in volume, with their inputs attached. Those are exactly the files the tape-out purge removed first, because they were large and they had failed.

Which of last year’s projects could you rebuild a training set from today?

Four kinds of files live in a regression tree, and each one needs a different rule.

The mistake is treating the scratch tree as one category. It holds at least four, and a retention policy that applies one rule to all of them either keeps everything or loses the useful part.

WHAT IS IS	THE OLD RULE	THE RULE WHEN MODELS NEED IT
Waveform dumps and full simulation traces	Delete on pass, keep briefly on fail	Keep a sampled set of fails with their run configuration, delete the rest
Logs, coverage reports, timing reports	Keep until sign-off, then delete	Keep all, they are small, and they are the labels
Checkpoints, intermediate netlists, place-and-route snapshots	Keep the final, delete the rest	Keep the ones that feed a superseding version, delete dead branches
Run configurations, seeds, tool versions, constraints	Rarely kept at all	Keep every one, without them the other three are unlabeled

The last row is the one most teams miss. A waveform dump with no record of the seed, the tool version, and the constraint set that produced it is a large file with no meaning. The configuration is the label, and a training set without labels is storage.

The recognition test is simple. Open the scratch tree from a project that closed 18 months ago and try to find the regression runs that failed on hold-time violations before the last constraint change. If the logs are gone, the question is unanswerable. If the logs are there but the configurations are gone, the answer is a list of files you can’t trust.

EDA data retention needs fields the file system does not carry.

Every retention decision in that table depends on knowing something the operating system does not record. Pass or fail. Which design version. Which seed. Whether a later run superseded this one. The file system gives you a name, a path, a size, an owner, and three timestamps, and those fields leave all four questions open.

This is why age-based cleanup, the policy most storage teams actually run, produces the wrong result for EDA. Age is the one attribute every file has, so it is the attribute the policy uses, and a failed corner run from a shipped project ages identically to a passed one. The policy keeps both or deletes both.

The fix is to attach the missing fields to the file record once the tree is indexed. Diskover indexes the regression tree in place, and enrichment plugins add the fields the file system lacks, some during the scan and some after it. Path Tokens turns the directory conventions your flow already follows (block, run, seed, design version) into searchable fields, the first links of the provenance chain. Breadcrumb reads a small metadata file your flow writes into each run directory, the run configuration itself, and attaches its contents to that run’s record. CSV maps the results export your regression manager already produces (verdict, tool version, constraint set) onto the matching runs or files. The supporting fields land in the enriched metadata catalog on each record, and a custom plugin covers any convention specific to your flow. The data stays in place while the catalog is built, and it moves only when a workflow calls for it.

Once those fields exist, the retention table above stops being a document and becomes a query. Select every waveform dump whose log verdict is fail, whose design version is within two of the tape-out version, and whose configuration file is present. That is a training set candidate, and it is also the list of files the policy protects when the purge runs.

Provenance is the axis, and age is a proxy that fails.

The question a verification engineer actually asks is never “how old is this.” It is “which run produced this result,” and behind it, “which inputs produced that run.” That chain, from a result back through a run to its configuration and its design version, is provenance, and it is the axis a retention policy for EDA should sort on.

Sorted by provenance, the scratch tree divides cleanly. Runs on the provenance chain of the shipped design are candidates for the training set. Runs on abandoned branches are candidates for deletion, and a model can still learn from a sample of them. Runs whose chain is broken because the configuration was lost or the log was truncated are the ones to delete first, since they cannot be trusted as data and take the same space as the ones that can.

That last category is where most of the capacity goes, because a run loses its label far more easily than it loses its dump. The configuration was a small file in a directory someone cleaned, and the 40 GB waveform it described is still there. Unlabeled is a fixable condition rather than a permanent one. Attach the fields, and the decision becomes obvious for most of it.

How much of your scratch tree could you label today from the run configurations still on disk?

Running the decision at scale, with a person approving it.

A regression tree for one large block can hold tens of millions of files. Across a site, it can hold billions, the scale at which directory walks stop completing and manual review is a fiction. EDA data retention has to run on a schedule, against the catalog rather than the file system, through policy-driven curation. That is what EDA data management means at this scale.

Diskover runs it that way, and it keeps a person in the loop where it matters. A verification lead can ask the catalog a plain-language question through the AI connector, which failed corner runs from the shipped version still have their configurations, and get back the matching files with a recommended action attached, tier to archive or delete, which they approve before anything moves. AI-assisted, human-approved. The approval is the step that turns a policy into a decision someone is accountable for.

Cloudera reports that nearly 80% of enterprises say limited data access is holding back their AI initiatives. In EDA, the access problem starts earlier than most: the data was deleted before anyone could have accessed it. Retention that runs against enriched fields is how the next project avoids inheriting that problem.

What the next project inherits.

Run this way, tape-out stops being a purge and becomes a curation step. The shipped design’s provenance chain goes to a tier where it costs less to hold and stays queryable. Abandoned branches get sampled and the remainder deleted. Broken chains go first. What remains is a labeled record of how the design was verified, sitting beside the record of how the last three were verified.

That is the training set. It was always being generated. The only change is that the files with the labels attached now survive the night after tape-out, and the ones without labels are the ones that go.

Which project closes next, and what will be left in its scratch tree the morning after?