Semi E139.1

SEMI E139.1 defines the XML schema for RaP's process-definition elements — the actual document structure a recipe uses to express its parameter sets, step sequencing, and conditional logic as a machine-parseable XML document, built on E138's shared common-component library, rather than the general download/verify/select lifecycle E139 establishes. E139 says a host should be able to download, verify, select, and version-control a recipe; E139.1 is the schema-definition companion that fixes precisely how a recipe's actual content — its gas flows, power steps, timing sequences, and any conditional branching the recipe includes — gets expressed as a structured XML document, rather than leaving the recipe's internal representation as an unspecified, often vendor-proprietary binary or text format.

SEMI E139 says: download, verify, select, version-control a recipe
Lifecycle defined, but the recipe's own internal structure is left open
SEMI E139.1 — XML schema for RaP process-definition elementsFixes the document structure for parameters, steps, and conditional logic
Standardized XML elements for parameter sets and step sequencing
Built on E138's shared timestamp/unit/ID component library
Defined structure for conditional logic within a recipe
Branching steps expressed consistently, not vendor-specific
A recipe authored for one tool parses the same way on any E139.1-compliant parser
No vendor-proprietary recipe format to reverse-engineer

The reason E139 needed its own schema-definition companion is the same gap nearly every lifecycle-management standard in this family closes the same way: being able to download and verify a recipe doesn't help if the recipe's actual content — the parameters and steps it's made of — has no standardized internal structure, because then "verify" can only mean checking a checksum, not meaningfully validating that a parameter is within range or that a step sequence is well-formed. E139.1 removes that gap by defining the XML elements a process-definition document is built from, reusing E138's common components for the basic pieces (timestamps, units, equipment IDs) rather than redefining them, so a host or third-party recipe-authoring tool can generate, validate, and parse recipe content against one shared schema instead of a per-vendor proprietary format.

An Actual E139.1 Recipe Document, Fully Expanded "verify the recipe" needs a defined structure to verify against <Recipe id="etch-v2.3" xmlns:e138="semi.org/e138"> <e138:Timestamp>2026-11-12T10:00Z</e138:Timestamp> <e138:EquipID>ETCH-04</e138:EquipID> — reused from E138, not redefined <Step n="1"> <Param name="RF_power" unit="e138:Watt">500</Param> <Param name="gas_flow" unit="e138:sccm">80</Param> </Step> <Step n="2"> <Param name="endpoint_detect">true</Param> <Conditional test="endpoint_signal > 0.9"> <Then>advance to Step 3</Then> <Else>hold, re-check in 2s</Else> </Conditional> </Step> </Recipe> Schema validates: is "500" in range for RF_power? Is the conditional well-formed? Without E139.1, "verify" could only mean checksum-match — not this

E139.1 completes RaP the same way every XML-schema companion completes its base lifecycle standard: E139 defines what a host can do to a recipe's lifecycle, and E139.1 is the fixed XML structure that makes the recipe's actual content — parameters, step sequencing, conditional logic — something a host or third-party tool can generate, validate, and parse consistently, instead of a vendor-proprietary format no two tools agree on.

Take SEMI E139.1 further

Ask the copilot about this term, or have our engineers assess it against your process.