Safety stop with facility source missing (incomplete evidence test)

1 source perspective · asset SIM-AMR-01 · scenario s01-no-facility

01 / Scope of analysis

Case SIM-2026-0004 (scenario s01-no-facility). Window: 14000.032 ms of robot recording on the ROBOT_ROS_TIME clock.

Sources: 9 robot topics (kinesim/0.1.0) and no facility records. Both sources are synthetic and were generated by logically separate components; neither is a physically independent witness.

02 / Recorded chronology

Event	Shared-clock time	Observation	Source
E-002	00:00.200 ±0.05 ms	Navigation goal executing	robot-controller-sim
E-003	00:11.018 ±2.55 ms	Robot safety I/O registers external stop input	robot-controller-sim
E-004	00:11.020 ±0.05 ms	Robot safety controller starts Category-1 controlled stop	robot-controller-sim
E-005	00:11.050 ±0.05 ms	Navigation goal aborted	robot-controller-sim
E-006	00:11.050 ±0.00 ms	Zero velocity command recorded on /cmd_vel	robot-controller-sim
E-007	00:11.930 ±10.05 ms	Odometry reports speed < 0.01 m/s held ≥ 200 ms	robot-controller-sim
E-008	00:12.140 ±0.05 ms	Robot safety controller reports drive power removed	robot-controller-sim

03 / Measured and derived facts

F-001Recorded sequence. E-003 Robot safety I/O registers external stop input → E-006 Zero velocity command recorded on /cmd_vel → E-007 Odometry reports speed < 0.01 m/s held ≥ 200 ms. Each step is ordered within its stated uncertainty. [E-003, E-006, E-007 · bounded interval under assumptions]

F-002Reported speed at stop input. Wheel odometry reports 1.196 m/s when the stop input is registered (E-003), interpolated between /odom samples #550 (1.202 m/s) and #551 (1.196 m/s). [E-003 · derived from recorded values]

F-003Stop input to zero velocity command. The first zero velocity command (E-006) is recorded 30 ms after the stop input (E-003), same robot clock. [E-003, E-006 · derived from recorded values]

F-004Stop input to reported stationary. Odometry reports the robot stationary (E-007) 899.876 to 925.069 ms after the stop input (E-003). Reported travel in that window: 0.561 m; mean reported deceleration 1.3 m/s². [E-003, E-007 · derived from recorded values]

F-005Nearest lidar return when stationary. The /scan message nearest the reported stop (#119) has its closest return at 3.675 m, bearing -135° (robot frame). [E-007 · recorded value]

F-006Robot position relative to the facility zone. At the stop input the odometry pose is (9.243, 5.291) m, 1.957 m outside the mapped boundary of ZONE-B2. [E-003 · derived from recorded values]

F-007Clock offset uncalibrated. No facility source is present, so no clock relationship can be derived. Cross-source ordering is not reported. [no events · absence of signal]

F-010Navigation goal outcome. The navigation goal is recorded as ABORTED (E-005); drive power removal is reported at E-008. [E-005, E-008 · recorded value]

04 / Gaps and limitations

F-008Source coverage and evidence gaps. 1 of 2 expected sources present. Not present in this case: camera, physical contact sensor, person detection, and the identity of whatever opened the facility input. [E-003 · absence of signal]

F-009Record continuity. /odom: 701 messages, largest gap 20.095 ms (nominal 20 ms). [no events · recorded value]

What the data cannot show.

Anything the facility controller recorded: that source is missing from this package.
What opened the facility zone safety input (a person, a test, an equipment fault): the facility source records the input change, not its cause.
Whether any person or object was in the zone: no camera or person-detection source is present.
Whether physical contact occurred: no contact sensor is present, and a speed drop does not imply a collision.
Whether odometry matches the robot's true motion: there is no external ground-truth tracking source.
The true clock relationship outside assumptions A1–A3.
Cause, fault or responsibility. These are not assessed by KINWIT.

05 / Questions for a human reviewer

Was the zone safety input opened by a person, an automated test, or an equipment fault? A separate source (door sensor, camera, operator log) is needed.
Is the declared PLC scan cycle (and therefore the detection latency bound) correct for the real controller?
Is the safety-link path facility → robot I/O the only path that could have produced the robot's stop input?
Would a measured clock reference (PTP / GNSS) be available on site to tighten the alignment interval?

06 / Non-attribution statement

This report orders and measures recorded events. It does not determine cause, fault, liability, regulatory compliance or the accuracy of the underlying sensors. Event order is not causation.

07 / Integrity

Manifest kinwit.evidence.v1, canonicalized with RFC 8785 (integer profile), signed with Ed25519 by kinwit-demo-signer-01 (fingerprint af1a 9a59 c6fc bd01 9be9 4785 6a3d f3e6 de04 b60d 82c3 93a1 5cd8 204c e0f4 beb5). Files are bound by SHA-256 and an RFC 9162 Merkle tree over 64 KiB chunks. Integrity verification shows that these bytes match what the key signed. It does not show that the simulated sensors are accurate.

File	Bytes	SHA-256
raw/robot_navigation.mcap	1318918	ecd149c7050cf086e22d5b65276a5da5d2b87bbbb870a8d84ab135984c3d8f8a
derived/timeline.json	96335	1bcb3258fc95d88c68b6b8bf431f75eb5669ee3e035a6921c827684715500592
derived/facts.json	9391	97a32f42b9f75204a78d3aa09d18e5539f4c9b62b87be016bbd27ba3cbf850ef
derived/report.json	13846	5867ace22bfa0e77a1779d6ca36accdfb17c9ad850fc2d0909c8e02c89d64e05

kinwit-facts/0.1.0 deterministic template (no AI) · manifest sha256 b1eea11aa57bb6ce50a75c0bb936ba4a6e559ad8e1596b8eaee904e85460af24 · SYNTHETIC DATA