Welcome back to The Battery Buildout.
In Part 1 (Project Master Planning and Process Design, Episode 01-08), we covered the decisions that define what the factory must do: the overview, the cell blueprint, the process route, the yield architecture, the material and energy balance, the site layout, the micro-environment, and the safety design. Part 2 (Equipment Selection & Digital Architecture) started from Episode 09, we discussed how equipment selection translates strategy into hardware. This edition addresses the documents that make that translation enforceable: the User Requirement Specification (URS) and the Key Process Technical Agreement. These are not procurement formalities. They are the legal and technical foundation of every FAT, every SAT, and every performance dispute that follows.
Table of Contents
1. The URS Is Where Process Physics Becomes a Contract
Did you treat URS as a checklist—a document that says what the equipment should do, written by the project team and filed away before the real work begins? This framing may miss its actual function.
The URS is the point where process physics becomes a contractual requirement. It translates the decisions made in Part 1—cell blueprint, process route, yield architecture, micro-environment specification, material and energy balance—into verifiable requirements that a supplier can respond to and that a project team can test against.
In a mature qualification lifecycle, the URS sits at the beginning of a traceable chain that connects design intent to final acceptance. Every requirement in the URS must ultimately become a test in the subsequent stages. If a requirement is ambiguous, untestable, or missing, the traceability chain breaks—and so does the project's ability to hold a supplier accountable. The specific qualification chain we apply in practice is calibrated to the project's regulatory environment, equipment criticality, and supplier risk profile.
Then what the URS should be?
2. The Quality Architecture of a URS That Works
A URS that can survive an acceptance dispute is not a narrative document. It is an engineered specification whose quality is defined by whether its requirements can be verified independently, traced to the Part 1 decisions that generated them, and enforced when performance falls short.
The specific quality architecture we apply in practice—and the criteria we use to assess whether a URS is fit for purpose—is calibrated to the project's specific conditions: the target market's regulatory requirements, the criticality of the equipment, the maturity of the supplier, and the project's risk tolerance. What appears as a well-written URS in one project may be insufficient in another, depending on these variables.
Let's continue exploring the complementary documents：Technical Agreement