Semi E142.1

SEMI E142.1 defines the XML schema for substrate mapping — the actual document structure a slot-occupancy result uses to represent which slots are occupied, which are empty, and which wafer identity correlates to which slot, built on E138's shared common-component library, rather than the general mapping-verification behavior E142 establishes. E142 says equipment must determine and report actual slot occupancy before any transport or process step proceeds; E142.1 is the schema-definition companion that fixes precisely how that occupancy result and wafer-identity correlation gets expressed as a structured XML document, the same relationship E139.1's XML schema has to E139's RaP lifecycle, so a host parsing a mapping report doesn't have to interpret a vendor-specific representation of "slot 7 is occupied by wafer X."

SEMI E142 says: verify actual slot occupancy before handling
Verification behavior defined, but no fixed document structure for the result
SEMI E142.1 — XML schema for substrate mappingFixes the document structure for slot occupancy and wafer-identity correlation
Standardized XML elements for per-slot occupancy status
Built on E138's shared timestamp/unit/ID component library
Defined structure correlating slot position to wafer identity
No vendor-specific interpretation of what a mapping result means
Host parses a mapping report the same way across any E142.1-compliant tool
No reverse-engineering a proprietary slot-status representation

The reason E142 needed its own schema-definition companion is the same gap every XML-schema standard in this family closes: a verification requirement in prose doesn't help a host software integration if the actual mapping result — which slots are occupied, which wafer is where — has no standardized document structure to parse, forcing every vendor's mapping-sensor report into its own ad hoc representation. E142.1 removes that gap by defining the XML elements a substrate-mapping result is built from, reusing E138's common components for the basic pieces rather than redefining them, so a host can validate and parse a mapping report against one shared schema regardless of which equipment vendor's mapping sensor generated it.

An Actual E142.1 Mapping-Result Document "verify slot occupancy" still needs a defined document to report it in <SubstrateMap carrierId="FOUP-8821" xmlns:e138="semi.org/e138"> <e138:Timestamp>2026-11-12T22:10Z</e138:Timestamp> <Slot n="1" status="occupied" waferId="W4471-01"/> <Slot n="2" status="empty"/> — mismatch vs manifest <Slot n="3" status="occupied" waferId="W4471-03"/> <Slot n="4" status="occupied" waferId="W4471-05"/> — cross-slotted <Slot n="5" status="occupied" waferId="W4471-04"/> </SubstrateMap> Any E142.1-compliant parser reads this identically status, waferId, and slot n are fixed field names — no vendor guessing Without E142.1, each vendor's mapping sensor invents its own report format

E142.1 completes substrate mapping the same way every XML-schema companion completes its base verification standard: E142 defines what has to be checked before handling proceeds, and E142.1 is the fixed XML structure that makes the resulting slot-occupancy and wafer-identity report something a host can parse consistently, instead of a vendor-specific format reinvented by every mapping-sensor manufacturer.

Take SEMI E142.1 further

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