Domain 1 Article Series · Part 3 of 6 | RSF Whitepaper v1.0 · §3.1–§3.3
The production manager has a launch date. The robot arrived two weeks late. The integrator is billing by the day, and everyone in the building knows the fastest way to make up lost time: cut commissioning short and start running parts. The robot moves, the cell works, what's left to test?
Every service engineer has been in some version of this meeting. RSF's answer to it is a mechanism borrowed from project management and rebuilt for robot service: the Stage Gate. And the framework attaches something unusual to it — not just a checklist, but a statement about who carries the consequences when the checklist is skipped.
What Phase 2 Actually Proves
Run-in and commissioning has a reputation problem. It looks like a slow-motion version of production: the robot runs cycles, engineers watch, nothing dramatic happens. If installation is done and the robot moves, commissioning can feel like a formality standing between the plant and its launch date.
The whitepaper frames it differently. Phase 2 exists to do one thing installation cannot: verify system behavior under real conditions, and record what “normal” looks like while the machine is still provably normal. It is the lifecycle's densest phase of what the whitepaper calls “investment information production” — every baseline recorded here pays back multiples in diagnostic efficiency later.
There is also a mechanical reason commissioning cannot be skipped: the run-in period is when a new machine settles. Manufacturing tolerances adapt under first dynamic loading, bearing surfaces smooth out, connector contact resistance stabilizes. Reliability follows the classic bathtub curve, and early-failure risk is real — but only detectable if someone is watching the right parameters: drive-current deviation from the no-load baseline, temperature rise trends, vibration signatures, and whether early TCP drift converges to a stable value.
The RSF training curriculum structures Phase 2 as five steps: trial production at reduced speed and load; safety system verification; performance benchmarking at full speed and full load — the numbers that become contractual KPI baselines; AI model validation where applicable; and baseline lock with formal client handover. The output of those five steps is the evidence the second Stage Gate demands.
Two Gates, Two Different Kinds of Protection
The whitepaper defines Stage Gates as state conditions, not schedule milestones: a phase transition happens when the evidence exists, not when the calendar says so. Its language on the alternative is direct — proceeding without satisfying a stage gate is “the systemic root cause of many service problems.”
The two gates bracketing Phase 2 protect against different failures. At the normative level, the whitepaper (Table 3.1-2) defines them as follows:
| Gate | Required Conditions (Whitepaper Table 3.1-2) | If Not Satisfied |
| SG1: P1 → P2 | ① Safety-function verification report completed and signed by the customer ② Initial Parameter Record archived, including load-inertia values ③ All wiring identification and grounding verification completed | Stop. Without verified safety functions, dynamic commissioning is forbidden — violates ISO 10218. |
| SG2: P2 → P3 | ① Accuracy-acceptance report meets application specifications (TCP error within allowable range) ② Performance-baseline file established (per-axis current baselines, vibration characteristic frequencies) ③ Delivery Acceptance Certificate (DAC) signed by both parties | Stop. Entering operations without baseline files leaves no reference for future anomaly judgement. |
SG1 is a safety gate: it exists because energizing a robot for dynamic motion before its safety functions are verified is not a schedule risk, it is an ISO 10218 violation. SG2 is an evidence gate: it exists because a robot entering production without its baseline file is the machine from Part 2 of this series — the one whose seven-year-old J3 alarm nobody could interpret, because there was nothing to compare it against.
Who Owns the Bypass
A checklist that can be waved through under schedule pressure is not a gate; it is a suggestion. What gives the RSF gates their force is that the framework names the consequence of bypassing them — and names who it lands on.
The RSF Professional training materials state it for each gate. For SG1:
“Proceeding without SG1 approval: liability for commissioning-phase safety incidents shifts to the engineer who authorized the bypass.” — RSF Professional curriculum, Module 1 · Subsection 1.5 |
Read that carefully. Not the installing company in the abstract, not the project. The engineer who authorized the bypass. RSF certification links competence tiers to authorization boundaries — and authorization cuts both ways. The authority to approve a gate is also the accountability for approving it badly. An engineer asked to “just sign it so we can start” is being asked to personally underwrite whatever happens next.
SG2's consequence is commercial rather than personal, and quieter — which makes it easy to underestimate:
“Proceeding without SG2 approval: performance KPI baseline is undefined, making SLA contract unenforceable from day one.” — RSF Professional curriculum, Module 1 · Subsection 1.5 |
An SLA promises availability, response, and performance against a measured reference. Skip the benchmarking step, and every number in that contract floats. When a dispute comes — the customer says throughput has degraded, the provider says it was always like this — there is no commissioning-time record to settle it. Both sides signed a contract that lost its evidence base before it started.
The Compensation Fallacy
There is a tempting middle path, and the training materials shut it down in one line: “Incomplete commissioning cannot be compensated by increased PM frequency.”
The logic of the fallacy goes: we'll skip some verification now, and make up for it by inspecting the machine more often once it's running. It sounds prudent. It confuses two different kinds of activity. Preventive maintenance detects deviation from a baseline — it answers “has anything changed?” Commissioning creates the baseline — it answers “what is normal?” Doubling the frequency of the first activity does nothing to supply the second. Inspecting a machine twice as often, against a reference that doesn't exist, produces twice as many readings nobody can interpret.
Back to the Meeting
So what does the engineer say to the production manager with the launch date? RSF's structure changes the shape of that conversation. Without a gate mechanism, “we need three more days of commissioning” is one professional's opinion against a schedule — and schedules usually win. With the gate mechanism, the conversation has different stakes on the table: the safety liability names an individual, the missing baseline voids the SLA's evidence base, and the checklist is a signed document that either exists or doesn't.
The engineer isn't asking for patience. The engineer is declining to personally absorb the project's schedule risk. That is a much easier position to hold — which is, in the end, what the gate is for. It is not there to slow projects down; it is there so that the person holding the line on quality doesn't have to hold it alone.
For engineers preparing for RSF Professional certification: know the normative gate conditions in Whitepaper Table 3.1-2, the five commissioning steps, and the run-in monitoring parameters in §3.3.1. For customers: the DAC you sign at SG2 is not paperwork — it is the moment your SLA's numbers acquire their reference point. Read the baseline file before signing.
Part 4 moves into the long middle of the lifecycle: Phase 3, the three-tier preventive maintenance structure, and the three PM strategy models — including why a three-shift robot on a single-shift maintenance plan is quietly aging at triple speed.
Read the full Phase 2 and Stage Gate specification RSF Whitepaper v1.0, §3.1–§3.3 — the five-phase model, gate conditions, run-in monitoring parameters, accuracy acceptance standards, and baseline specifications. Free download. rsf.robottoday.com |
RSF (Robotics Service Framework) is an initiative of RobotToday.com. International standards cited are referenced for descriptive purposes; the official published text of each standards organization remains authoritative. Stage Gate normative conditions follow RSF Whitepaper v1.0 Table 3.1-2; expanded gate checklists and liability statements quoted are from the RSF Professional training curriculum (Module 1), which operationalizes the whitepaper for course delivery. Liability statements describe RSF's professional-accountability framework and do not constitute legal advice; actual legal liability depends on applicable law and contract. The opening scenario is illustrative. This article does not constitute a compliance certification document.
Leave a comment