1. Purpose and scope
The pilot is the first time a candidate tool meets company design data. Its purpose is learning, not proof. By the end the team should know, with examples, what the tool does well on this flow step, where and how it fails, how much review its outputs need, how it would fit into the existing scripts and data formats, and whether the benefit in the business case still looks real. Formal proof comes later, in Tool Qualification, on locked versions and the full reference set.
Two disciplines make a pilot useful. The first is that every output is checked against the known answer, not sampled and not judged by how plausible it looks. The second is that the engineers who own the flow step do the checking, because they are the people who can tell a subtly wrong constraint, assertion or placement from a correct one. A pilot run only by enthusiasts or only by the supplier's application engineers tends to report what worked and forget what did not.
In scope: running each shortlisted candidate and the conventional step on the reference designs, reviewing every output, recording failures with examples, collecting user feedback, starting a data preparation pipeline and updating the business case. Out of scope: use on any live project, use of data beyond the pilot data handling approval, version locking and formal accuracy measurement, and any production terms with a supplier.
12 more sections for registered members.