Etch Recipe Version Control
# Etch Recipe Version Control
Etch recipe version control preserves the identity and history of a process program as it is changed, qualified, released and executed. It connects a particular set of instructions and dependencies to the evidence supporting its intended use.
A recipe label is useful for selection, but it does not necessarily identify the complete content or prove which instructions actually ran.
## Preserve a specific revision
When a change is proposed, retain the previous controlled version and record what changed. Relevant differences can include step order, values, endpoint logic, referenced sub-recipes and other dependencies. A small-looking edit can affect a different response or process transition than the one being optimized.
The diagram is a conceptual lifecycle, not an implementation specification or a prescribed fab approval policy. Qualification scope, access roles, release controls and naming conventions belong to the actual equipment and manufacturing system.
A comparison should distinguish a descriptive label from a version and from the content associated with that version. An exported file may also depend on external definitions or equipment software behavior. Identifying the file alone is insufficient if those dependencies affect execution and are not recorded.
## Check the approved and loaded identities
The example uses the same recipe name, POLY_MAIN, in both columns. The approved revision is 17 with illustrative content identifier A, while the loaded revision is 18 with identifier B.
The recipe names match, but the versions in this example differ. That is a discrepancy to resolve through the established process; it is not evidence that revision 18 has the same qualification as revision 17.
A content identifier can help compare stored artifacts when its scope and calculation are defined. For example, a cryptographic digest can detect changes to the bytes it covers. It does not, by itself, prove that a recipe is appropriate, approved, safe for a particular stack or complete with all dependencies. Different serialization can also produce different byte digests for instructions intended to be equivalent, so define what is being compared.
## Link qualification to scope
Record which revision, chamber configuration, material stack, patterns and measurement methods were used for qualification. Keep the associated acceptance criteria and results with that identity.
Changing one parameter may alter depth, CD, profile, selectivity, residue or exposure of a protected layer. Verify the responses relevant to the intended module rather than assuming that an improvement in the primary metric preserves all other requirements.
Evidence from one chamber, recipe family or incoming condition does not automatically qualify every other use. Dependencies and operating context can make two nominally similar executions materially different.
## Record what actually executed
The intended released version, the loaded program and the executed run are related but distinct records. Where the system supports it, preserve the run identity, wafer or lot association, chamber, relevant configuration, recipe revision and applicable actual execution information.
Runtime substitutions, overrides or endpoint-driven transitions can matter to the interpretation of a result. Record them according to the implementation rather than assuming the stored nominal recipe describes every aspect of the run. A filename or timestamp alone may not distinguish all meaningful changes.
## Keep recovery and change history reviewable
Retaining a previous revision helps reconstruct history and evaluate recovery options. Reusing an old recipe is not automatically valid after hardware, software or material changes. Confirm the compatibility and qualification required for the intended current conditions.
Avoid silently replacing historical content under the same controlled identity. A process comparison becomes difficult to interpret if its referenced version no longer identifies the instructions used. Preserve the relationship among the change, review, qualification and execution evidence.
The useful record answers which instructions ran, under what conditions, and what evidence supported that use. Naming and storage are parts of version control; traceable identity and scope make it useful to process engineering.
## Sources and scope
- [SEMI — E42 recipe-management catalog and abstract](https://store-us.semi.org/products/e04200-semi-e42-recipe-management-standard-concepts-behavior-and-message-services): historical recipe-management concepts; the catalog marks this edition inactive.
- [Synopsys/BISTel — Recipe Management System overview](https://www.synopsys.com/content/dam/synopsys/silicon/datasheets/bistel-erms.pdf): an example of recipe-management software in semiconductor manufacturing.
- [Lam Research — Equipment Intelligence overview](https://newsroom.lamresearch.com/what-is-equipment-intelligence-semi-101): equipment-data and process-control context.
Original lifecycle and identifier example. This guide does not claim compliance with a SEMI standard or prescribe an equipment protocol, database design or manufacturing release policy.