Demonstration Protocol — Intrinsic

Foreword. This Test Protocol is new in the VRS 2026 edition. It exists because the Certified tier (VRS-GEN-003 §6.8) is earned by witnessed behaviour, and a witnessed behaviour has to be specified somewhere so that every manufacturer performs the same steps, every observer marks them the same way, and every reviewer can score them from the record alone. The steps here are derived from the intrinsic criteria in VRS-GEN-101 to VRS-GEN-107: each step names the criterion subclause that requires it, and no criterion is cited that does not, in its own Certified row, call for a demonstration. The standards themselves carry no step identifiers; traceability runs from this Protocol to the standards, never the other way. The session model is deliberately modest — one portable camera, the robot’s own console or a purpose-built live view, manufacturer-supplied apparatus sized to the manufacturer’s own claims, a native-format export — so that a stock-standard unit on a factory floor can be assessed over a video call, in person, or at a laboratory with identical results (VRS-GEN-003 §6.9 route parity). Sector demonstration protocols (VRS-<CODE>-110) extend this Protocol with sector-specific steps; they never repeat or alter its steps. As a protocol it is versioned vX.Y.Z (VRS-GEN-004 §5.4). Requirements use “shall”; recommendations use “should”.

Introduction

A rating that claims to reflect how a robot behaves must at some point watch the robot behave. The precedent bodies that do this well — vehicle crash-test programmes, product-safety marks, equipment classification societies — share a structure: a published, fixed test sequence; apparatus whose dimensions follow the product’s own declared limits; an independent observer; and a record that a person who was not present can score. This Protocol adopts that structure and strips it to what a small manufacturer can actually deliver without a laboratory: the camera is a phone, the instrument is the robot’s own data feed, the test mass is whatever the manufacturer says the robot carries, shown on their scale. Nothing is installed on the robot, no network access is required, and nothing is done to a person. What the observer sees, the reviewer can replay.

The Protocol is intrinsic: it covers the criteria that apply to every robot model regardless of sector — safety functions, specification claims, serviceability, cyber controls and the consistency of the session record with the robot’s own logs. Sector-specific behaviour (a pick rate at a conveyor, a return-to-home on lost link at altitude, a release time for a wearable) is the business of the sector demonstration protocols, which begin where this Protocol ends.

1 Scope

This Protocol specifies the demonstration steps, session requirements, step order, apparatus rule, failure handling and record format by which the intrinsic criteria of VRS-GEN-101 to VRS-GEN-107 are demonstrated at the Certified tier. It applies to every Certified assessment of every robot model in every sector, by every Certified route of VRS-GEN-003 §6.9 (Veyrum-witnessed remote, Veyrum-witnessed in person, accredited-laboratory witnessed).

It specifies: the mandatory session requirements (Clause 4); how steps are identified, ordered and read (Clause 5); the steps themselves (Clause 6); how an observer’s marks reach a criterion score (Clause 7); and the Session Record (Clause 8). Annex A maps every intrinsic criterion to its steps or states that it has none.

It does not: define any criterion, point value, ceiling or ladder (those are in VRS-GEN-101 to VRS-GEN-107 and are frozen by VRS-GEN-004 §8); define the Verified information pack (VRS-GEN-013); define sector steps (VRS-<CODE>-110); or define the Unverified path (VRS-GEN-204). Long-duration endurance, destructive tests and tests on people are outside this Protocol by construction: the bounded in-session endurance sample (steps GEN-203.18 and GEN-203.40) is the only endurance witnessed, and every contact or entrapment step uses a compliant target or a test object.

2 Normative references

• VRS-GEN-001, Vocabulary and Terminology — tier, ceiling, rung, evidence bar, edition stamp.
• VRS-GEN-002, Document Structure and Template Rule — document types, criterion layout, priors.
• VRS-GEN-003, Governance Charter and Independence — assurance tiers (§6.8), Certified routes and route parity (§6.9), attestation (§6.10).
• VRS-GEN-005, Intrinsic Rating Methodology — point-sum, tier ceilings, cold-start parity (§6).
• VRS-GEN-009, Passport and Registry Schema — the Session Record reference carried by a Certified rating.
• VRS-GEN-012, Evidence Grades and Data Requirements — evidence admissibility, provenance and consent.
• VRS-GEN-101 to VRS-GEN-107, the seven intrinsic-criterion standards whose Certified rows this Protocol serves.
• VRS-GEN-104, Specification Integrity — the declared claims that size every apparatus in Part C.

3 Terms and definitions

Terms defined in VRS-GEN-001 apply. In addition:

3.1 session — one continuous witnessed demonstration, from the session code shown at open to the session code shown at close, covering this Protocol and, where applicable, one sector protocol.

3.2 session code — the unique code issued by the Session tool for a session, shown on camera at open and at close to bind the footage to the session.

3.3 observer — the person, acting for Veyrum or for an accredited laboratory under VRS-GEN-003 §6.9, who advances the steps and marks each one in the Session Record.

3.4 demonstrator — the manufacturer’s representative who operates the robot and the apparatus.

3.5 data feed — the live, human-readable view of the robot’s state screen-shared during the session: either the robot’s real HMI or diagnostic console, or a purpose-built view carrying the fields of 4.4.

3.6 apparatus at declared value — a test object, mass, distance, slope, obstacle or condition supplied by the manufacturer and dimensioned to the manufacturer’s own declared claim for the model, with the dimension or mass shown on camera.

3.7 stock-standard unit — a unit of the model as delivered to a customer: no non-production hardware, test harness, tether or software beyond the customer configuration.

3.8 step — one witnessed outcome with a fixed identifier, a witness means, an apparatus requirement, a time bound and the criterion subclause(s) that require it.

3.9 declined step — a step the manufacturer chooses not to perform; recorded as declined and scored as zero on the criterion it serves, without effect on any other criterion.

3.10 not-declared step — a step whose subject the manufacturer has not claimed (a protective function not declared, a headline claim not made); recorded as not declared and without effect on any score.

3.11 compliant target — a deformable or instrumented object that stands in for a person in any contact, force or entrapment step.

3.12 Session Record — the sealed record of a session: recording, screen-share, uploads, the step timeline with the observer’s marks, and their hashes (Clause 8).

3.13 witness means — the way an outcome is confirmed: CAM (camera alone), FEED (data feed alone), CAM+FEED (camera correlated with the feed), CAM+APP (camera with apparatus), CAM+FEED+APP, or EXPORT (from the uploaded export after the session).

4 Session requirements

4.1 A Certified demonstration shall satisfy every requirement in 4.2 to 4.9. A session in which any one of them is not met shall not yield Certified points on any criterion; the assessment continues at the Verified tier on the information pack (VRS-GEN-013).

4.2 One camera, one code. One portable camera shall carry the observation perspective for the whole session, recording continuously from open to close. The session code shall be shown on that camera at the open (GEN-203.01) and at the close (GEN-203.41). No second camera is required or admitted as the primary record.

4.3 Pre-supplied script, fixed order, observer-paced. The manufacturer shall receive the full step list — this Protocol plus the applicable sector protocol — before the session. Steps run in the published order. The observer advances each step when satisfied; the demonstrator’s screen shows the current step. Rehearsal is expected.

4.4 Live data feed. The manufacturer shall screen-share a live data feed for the whole session. The feed shall show, live: robot identity (model, serial, hardware revision, software/firmware version); operating mode or state (autonomous, manual, paused, e-stop, fault); safety state (active safety functions, e-stop status, last protective stop and its trigger); motion (current speed; payload or load reading where sensed); energy (battery or charge level, power state); active faults or alarms; a cycle or task counter; and a visible clock. The real HMI or a purpose-built page fed from the robot’s data are equally acceptable.

4.5 Native-format export. After the close the manufacturer shall upload the robot’s own log export covering the session window, in whatever machine-readable format the robot produces (a screenshot is not an export). The export shall contain: model, serial and firmware identity; the fault or alarm log with timestamps; the safety-controller event log (protective stops, e-stops) where the robot has one; cycle, task or operating-hour counters at open and close; and timestamps with a stated time zone. The Session tool hashes the file on receipt.

4.6 Stock-standard unit. The unit demonstrated shall be a stock-standard unit (3.7). The demonstrator shall declare this on camera (GEN-203.05).

4.7 Apparatus per claim. Every apparatus dimension, mass, distance, slope and condition shall be taken from the manufacturer’s own declared claims for the model as stated in the information pack. The manufacturer supplies the apparatus and shows its dimension or mass on camera. The Protocol never fixes a number: a manufacturer that declares less demonstrates less and is scored against the smaller claim (VRS-GEN-104).

4.8 Nothing on a person. No step shall place a person in the path of motion, in contact with the robot under power, or in an entrapment position. Contact, force and entrapment steps use a compliant target or test object.

4.9 Version proof. The running software and firmware version shall be shown on the robot’s own console or on the data feed at the open (GEN-203.03) and shall lie within the rated version range declared in the information pack.

4.10 Confidential robots and thin telemetry. A manufacturer that cannot expose its real console shall meet 4.4 with a purpose-built live view carrying the required fields; a robot with little telemetry shall meet 4.5 with an export carrying the required content. No exemption from, and no ceiling reduction for, either requirement is available on grounds of confidentiality or telemetry depth.

5 Reading and running the Protocol

5.1 Step identifiers. Each step carries a fixed identifier of the form GEN-203.nn. The identifier is the Session Record step identifier and the key by which the reviewer’s scoring worksheet, the registry (VRS-GEN-009) and any appeal refer to the step. Sector protocols use <CODE>-110.nn. Identifiers are never reused; a step withdrawn in a later version keeps its number, marked withdrawn.

5.2 Required by. Every scored step carries a Required by reference to the criterion subclause(s) of VRS-GEN-101 to VRS-GEN-107 whose Certified row it serves. The standards carry no reference back to this Protocol. Where a step serves more than one criterion, each is listed and the step’s result feeds each of them.

5.3 Order. Steps run in Part order A to F and in numerical order within a Part. Part A shall be complete before the first scored step; Part F closes the session. The applicable sector protocol runs between Part E and Part F of this Protocol, so that one export covers both.

5.4 Declared subjects. Steps GEN-203.09 to GEN-203.13 are run for each protective function the manufacturer has declared as a primary protective function; at least one shall be declared and run. Steps GEN-203.19 to GEN-203.27 are run for each headline or secondary claim the manufacturer has made; a claim not made is recorded as not declared (3.10).

5.5 Time bounds. Each step carries a bound in minutes. The observer may end a step at its bound and mark the outcome observed to that point. The sum of bounds over Parts A to F, counting each of GEN-203.09 to GEN-203.13 once, is 348 min; a typical session with two or three declared protective functions runs three and a half to five hours. Steps marked post-session have no live bound.

5.6 Failure. A step the robot cannot complete is marked not achieved and scores zero on the criterion subclause(s) it serves; the session continues. A declined step (3.9) is marked declined and scores zero likewise. Neither mark affects any other criterion.

5.7 Venue parity. The same step, witnessed remotely, in person or at an accredited laboratory, yields the same mark. A laboratory route shall use the same Session tool and produce the same Session Record (VRS-GEN-003 §6.9).

5.8 Integrity controls. The controls against a staged or pre-recorded demonstration are the session code (4.2), the live feed correlated with the camera (4.4), and the post-session consistency steps GEN-203.43 to GEN-203.45 that reconcile the robot’s own export with what was witnessed. The Protocol does not rely on surprise: steps are published and rehearsable.

6 The steps

Columns: ID — Session Record step identifier · Step — outcome to witness · Witness — means (3.13) · Apparatus — manufacturer-supplied, at declared value (4.7) · Bound — minutes · Required by — criterion subclause(s) served, or the session precondition the step satisfies.

6.1 Part A — Session open (integrity preconditions)

Preconditions for any Certified point (4.1). Steps GEN-203.02 and GEN-203.03 also serve a criterion.

6.2 Part B — Safety functions

The e-stop, energy and restart steps run first for every robot. Steps GEN-203.09 to GEN-203.13 run for each declared primary protective function (5.4).

6.3 Part C — Specification claims

Every declared headline claim receives a step; the endurance sample opens here and closes in Part F. Apparatus is sized to the declared value (4.7).

6.4 Part D — Serviceability

The manual’s own procedures are the script; the observer marks completion and takes time from the video.

6.5 Part E — Cyber controls

Shown on the robot’s own console through the data feed (4.4). The conditional environmental sample runs here where a declared condition is present at the site.

6.6 Part F — Close and records

The three post-session steps are scored by the reviewer from the uploaded export and the Session Record.

6.7 Timing budget. Part A 9 min · Part B 115 min if every protective function is declared (60 min plus the declared functions among GEN-203.09 to GEN-203.13) · Part C 86 min · Part D 55 min · Part E 75 min including the conditional sample · Part F 8 min live. Total 348 min (5.8 h) with every protective function declared and a site condition present; a typical session — two declared protective functions, no site condition — is 293 min (4.9 h), within the half-day the Protocol is designed for. The endurance sample runs in the background and adds no time.

7 From marks to scores

7.1 For each step the observer records one mark: achieved, achieved with note, not achieved, declined, not declared or not run, with the time and any observation. Marks are made in the Session tool during the session and cannot be edited after the close.

7.2 The reviewer, who may be the observer or another person, scores each criterion from the Session Record alone. For a criterion served by one or more steps, the reviewer reads the criterion’s ladder in its own standard and places the witnessed outcome on a rung; the Certified ceiling of that criterion is available only where every step serving it is marked achieved or achieved with note. A not achieved or declined step scores zero on that criterion.

7.3 A criterion whose Certified row reads “From Verified evidence” has no step in this Protocol and is scored at the Certified tier from the information pack at that criterion’s Certified ceiling (Annex A). A criterion whose Certified row reads “documentary” likewise. The information pack itself is attested under VRS-GEN-003 §6.10; the Session Record needs no attestation because the Session tool produces it.

7.4 Steps GEN-203.43 to GEN-203.45 are scored after the export is received. Where the export does not contain an induced event that the recording shows, or shows counters or identity inconsistent with the session, the reviewer shall record the inconsistency; it scores on the criteria those steps serve and shall be reported to the governance body under VRS-GEN-003 as a possible integrity matter. No other criterion’s score is changed by it.

7.5 Where a step could not be run because a session requirement of Clause 4 failed mid-session (loss of feed, loss of recording), the session is closed and the steps not yet run are marked not run; a continuation session may be scheduled under a new session code, and only steps marked not run are performed in it.

7.6 The Protocol produces marks, not points. Points, ceilings and the intrinsic total are computed under VRS-GEN-005 from the criterion standards; the letter of any sector rating is computed under VRS-GEN-006 and the sector’s -201. Nothing in this Protocol changes a rung, a ceiling or a total.

8 The Session Record

8.1 The Session tool shall produce one Session Record per session containing: session code, date and venue route; the identities of observer and demonstrator; the model, serial, hardware revision and software version as shown at the open; the full step timeline with each step’s identifier, mark, time and observer note; the hash of the continuous recording and of the screen-share capture; the hash and filename of every upload; and the applicable versions of this Protocol and of the sector protocol run.

8.2 The Session Record shall be issued as a human-readable document and as a machine-readable file, both hashed, and shall be immutable once issued. Its reference is carried by the Certified rating in the registry (VRS-GEN-009) and by the certificate.

8.3 Appeals (VRS-GEN-008) against a Certified score are decided on the Session Record. A manufacturer disputing a mark may request a continuation session (7.5) for the disputed steps; the original marks remain on the record.

9 Worked example (informative)

A manufacturer of a hypothetical autonomous mobile manipulator declares, in its information pack: a 25 kg payload, 1.5 m/s maximum speed, 1.1 m reach, 20 mm step capability, ±2 mm repeatability, a representative task of 40 picks per hour, 6 h runtime, and protective stop on detection as its primary protective function with a 70 mm minimum detectable object and a 300 mm stopping distance. It declares one field-replaceable module (the lidar unit) and no environmental tolerance claim.

The session opens at 09:00. GEN-203.01 to GEN-203.05 take eight minutes; the feed is the manufacturer’s own diagnostic web page. Part B: e-stop from the hardware button, the tablet HMI and the fleet console (GEN-203.06); low-battery behaviour and the charging interlock (GEN-203.07); restart interlocks (GEN-203.08); protective stop at 1.5 m/s against a 70 mm cylinder entering the field, stopping short of a floor mark at 300 mm (GEN-203.09, achieved); GEN-203.10 to GEN-203.13 marked not declared; degraded sensing with the lidar window half-taped (GEN-203.14, achieved with note: slowed rather than stopped, as declared); lost link by switching off the site Wi-Fi (GEN-203.15); torque-limit release on a foam block (GEN-203.16); stability with the 25 kg mass on the manufacturer’s 5° ramp (GEN-203.17). Part B closes at 10:05.

Part C opens the endurance sample at 10:06 with 92 % charge and cycle counter 1 412 (GEN-203.18). The 25 kg mass is weighed on the manufacturer’s scale on camera and carried through the declared motion (GEN-203.19); speed over a 10 m marked run, timed from video at 6.9 s against a feed value of 1.48 m/s (GEN-203.20); reach markers (GEN-203.21); a 20 mm step built from a marked plate (GEN-203.22); five returns to a marked pose within the manufacturer’s gauge (GEN-203.23); twenty picks in 28 min — the feed counter and the video agree (GEN-203.24); three navigation goals with a placed box handled (GEN-203.25); the declared object set handled ten times, nine successful (GEN-203.26, achieved with note); the manufacturer’s sound meter shows the declared level on camera (GEN-203.27). Parts D and E run from 11:35 to 12:40: an induced lidar-disconnect fault cleared per the manual (GEN-203.28); pack swap in 4 min (GEN-203.29); lidar unit swap in 22 min (GEN-203.30); diagnostics reached from the operator login (GEN-203.31); default credentials refused, roles shown (GEN-203.32); a signed update applied and an unsigned one refused (GEN-203.33); rollback (GEN-203.34); remote access enabled and disabled (GEN-203.35); offline picking shown with fleet reporting degraded (GEN-203.36); telemetry page (GEN-203.37); security log (GEN-203.38); GEN-203.39 not present. Part F: the endurance sample closes at 12:42 with 71 % charge after 156 min of representative duty, extrapolating to about 12 h (GEN-203.40); session code at close (GEN-203.41); the export is uploaded at 12:50 (GEN-203.42). The reviewer later confirms the e-stops, protective stop and lidar fault in the export at matching times, the counter advance and the identity (GEN-203.43 to GEN-203.45). Total live time: 3 h 50 min.

The reviewer scores VRS-GEN-104 SI-2 with every headline claim achieved at the declared value, one with note, and reads the rung from that standard; VRS-GEN-101 SF-4 from GEN-203.09 alone, the other protective-function steps being not declared; VRS-GEN-102 RL-6 from the 156 min sample. No number in this example is a requirement; every apparatus value came from the manufacturer’s own declaration.

Annex A (normative) — Criterion coverage

Every intrinsic criterion of VRS-GEN-101 to VRS-GEN-107 appears once. A criterion with steps is demonstrated by exactly those steps. A criterion without steps is scored at the Certified tier as stated (7.3).

Annex B (informative) — How a sector protocol extends this one

A sector demonstration protocol VRS-<CODE>-110 lists only the steps its sector criteria require that this Protocol does not already witness — envelope-limit repeats of the protective-function steps at the sector’s declared limits, and sector-specific outcomes (a release time for a wearable, a return-to-home on lost link at altitude, a surface-on-lost-link for a submersible, a pick rate at a conveyor). It uses the same session, the same feed, the same apparatus rule and the same export. Its steps are identified <CODE>-110.nn, carry Required by references to the sector’s -201 subclauses, and run between Part E and Part F of this Protocol (5.3). It should add no more than two hours to the session.

Bibliography

• ISO 10218-1:2025, Robotics — Safety requirements — Part 1: Industrial robots.
• ISO 10218-2:2025, Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells.
• ISO/TS 15066:2016, Robots and robotic devices — Collaborative robots (power-and-force limiting, body-region thresholds).
• ISO 13849-1:2023, Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design.
• IEC 62061:2021, Safety of machinery — Functional safety of safety-related control systems.
• ISO 3691-4:2023, Industrial trucks — Safety requirements and verification — Part 4: Driverless industrial trucks and their systems.
• ISO 13482:2014, Robots and robotic devices — Safety requirements for personal care robots.
• ISO 9283:1998, Manipulating industrial robots — Performance criteria and related test methods (pose repeatability and accuracy).
• IEC 62443-4-2:2019, Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components.
• ISO/IEC 17020:2012, Conformity assessment — Requirements for the operation of various types of bodies performing inspection (witnessed inspection).
• ISO/IEC 17025:2017, General requirements for the competence of testing and calibration laboratories (accredited-laboratory route).
• Euro NCAP, Assessment Protocol — Overall Rating, v10.0 (2024) — fixed published test sequence against product-declared configurations.

Change history