[PoC] CLIM: Open-RMF-style Delay Advisory and Evidence Windows for command-feedback integrity

[zc_Liu]

Hi Open-RMF community,

I have working on a small proof-of-concept called CLIM — Causal Link Integrity Middleware. The goal is to explore whether a robot can report not only that it is delayed, but also why the current command-feedback execution window is no longer trustworthy.
This started from a ROS 2 /cmd_vel guard experiment, ros2_kinematic_guard, where I tested bad Wi-Fi / 5G timing effects such as stale commands, burst delivery, near-zero dt, and command-feedback phase mismatch.
After reading the Open-RMF next-generation traffic management discussion around ~/delay, progress reporting, and Plan Executor / Plan Server coordination, I wanted to test whether CLIM could act as an advisory-only evidence provider.

CLIM does not publish Open-RMF messages directly. Instead, it emits structured JSON that a Plan Executor or fleet adapter could choose to map into future RMF delay/progress interfaces.

1. Command Execution Integrity

This is the main CLIM signal. It asks:

Can the Plan Executor still trust this execution episode?

Example from a Wi-Fi collapse stress test:

{
  "commandExecutionIntegrity": {
    "residual": 5.391,
    "residualType": "kinematic_consistency",
    "latencyClass": "CRITICAL",
    "causalAlignment": "BROKEN",
    "executionState": "RESYNCING",
    "guardAction": "BRAKE_AND_RESYNC",
    "dominantCause": "PHASE",
    "recommendedVehicleResponse": "RESYNC_REQUIRED",
    "suggestedFleetAction": "HOLD_NEW_ORDERS",
    "cleanWindowCount": 0,
    "requiredCleanWindowCount": 5
  }
}

In this case, CLIM is not simply saying:

The robot is late.

It is saying:

The command-feedback chain is no longer causally aligned.
The dominant cause is PHASE mismatch.
The robot is in RESYNCING.
The fleet layer should hold new orders until clean execution windows are observed.

As shown in the integrity report, CLIM automatically suggests HOLD_NEW_ORDERS when the causal residual spikes, providing a safety buffer for the fleet controller.

2. Delay Advisory

This is an Open-RMF-style advisory signal. It does not claim to be an official RMF ~/delay message.
It simply tells the Plan Executor:

This robot may need to report delay or hold progress near this progress point.

Example:

{
  "delayAdvisory": {
    "advisoryOnly": true,
    "shouldReportDelay": true,
    "planId": "demo_plan_001",
    "progressPoint": 0.63,
    "indefiniteDelayCandidate": true,
    "delayConfidence": 0.75,
    "cause": {
      "code": "EXECUTION_INTEGRITY_DEGRADED",
      "message": "Command-feedback causal alignment is broken. Dominant cause: PHASE.",
      "dominantCause": "PHASE"
    },
    "recommendedVehicleResponse": "RESYNC_REQUIRED",
    "suggestedFleetAction": "HOLD_NEW_ORDERS"
  }
}

3. Evidence Window

This is the black-box record. It captures the short command-feedback window that caused the advisory.

Example:

{
  "evidenceWindow": {
    "progressPoint": 0.63,
    "causalAlignment": "BROKEN",
    "latencyClass": "CRITICAL",
    "residual": 5.562,
    "dominantCause": "TIMEFLOW",
    "statusSequence": [
      "RESYNCING",
      "RESYNCING",
      "RESYNCING"
    ],
    "components": {
      "timeflow": 5.0,
      "phase": 0.923,
      "cmd_odom": 0.033
    }
  }
}

The idea is to make delay reporting explainable instead of only timeout-based.
For example:

Was the robot actually blocked?
Was the command stream stale?
Was feedback lagging?
Did the command-feedback phase break?

4. Resync State

This explains whether the robot is still waiting for clean execution windows before being trusted again.
Example:

{
  "resyncState": {
    "state": "RESYNCING",
    "latencyClass": "CRITICAL",
    "causalAlignment": "BROKEN",
    "cleanWindowCount": 0,
    "requiredCleanWindowCount": 5,
    "isReleaseReady": false,
    "advisoryOnly": true
  }
}

This could help a Plan Executor decide whether to continue, wait, request replanning, or hold progress.

Why I think this may be relevant to Open-RMF

My understanding is that future Open-RMF traffic management interfaces are moving toward clearer separation between:

• Plan Server
• Plan Executor
• robot adapter / driver
• progress reporting
• delay reporting
• resynchronization
  CLIM tries to provide a quantitative signal for one question:
  Should the Plan Executor still trust this execution episode?
  It is intentionally advisory-only.

The Plan Executor or RMF adapter should remain responsible for deciding whether to publish a real delay, pause, request replanning, or continue.

Repository

GitHub:
CLIM(Causal Link Integrity Middleware)
Related ROS 2 guard experiment:
Stop “Ghost Commands” on Bad Wi-Fi: ros2_kinematic_guard for /cmd_vel safety

I would appreciate feedback from Open-RMF developers:

1. Could a CommandExecutionIntegrity / DelayAdvisory signal be useful before publishing a real ~/delay?
2. Would an EvidenceWindow be useful for debugging multi-vendor execution issues?
3. Is this better positioned as a Plan Executor plugin, a robot adapter-side diagnostic node, or a separate observability layer?

[grey]

Hi @zc_Liu , thanks for this write-up. I appreciate that you’ve taken the time to understand the Next Gen Open-RMF draft and how your idea fits into it.

1. Could a CommandExecutionIntegrity / DelayAdvisory signal be useful before publishing a real ~/delay?

One detail I’ll point out is that the current Next Gen proposal is to have a ~/plan/progress topic rather than a ~/delay topic. The logic is that ~/plan/progress gives a positive statement that the robot has definitely made at least a certain amount of progress along its plan, but this information should always be viewed as potentially out of date. The delay of the robot can be inferred from its progress along the plan so it won’t be necessary to publish it separately, although we could certainly define an optional extension for explicitly publishing the delay.

That detail aside, I agree that the CommandExecutionIntegrity and DelayAdvisory are good concepts to define and include as optional components that would serve two roles:

1. Factoring into how progress is calculated
2. Explaining and diagnosing operational issues

I can think of two alternatives for how we can incorporate these ideas into the Next Generation Interfaces:

1. Introduce new topics, such as ~/plan/execution_integrity and/or ~/plan/delay_advisory
2. Introduce a ~/plan/progress/error topic that publishes the PlanError.msg message. CommandExecutionIntegrity and DelayAdvisory would each have a CODE_ constant defined that would be used in the Error::code field. Each would also have a JSON schema defined that would be used in the Error::parameters field of PlanError::error. By posting this message to ~/plan/progress/error we would be cautioning the progress supervisor (the node that calculates the current progress) that there may be additional factors to consider before finalizing the latest progress report.

2. Would an EvidenceWindow be useful for debugging multi-vendor execution issues?

I might need you to elaborate on how EvidenceWindow is created and how it gets used. Is it just for logging purposes so that operators can look back and identify the cause of failures?

3. Is this better positioned as a Plan Executor plugin, a robot adapter-side diagnostic node, or a separate observability layer?

My instinct is that the components you’ve described would be best to run on-board the robot platform itself. That would be the location where the relevant information streams can be reliably synchronized to identify if anything is out of phase. I would probably implement it inside the “robot adapter” as you called it, where commands about what to execute are received and processed.

[zc_Liu]

Hi @grey,

Thank you for the detailed feedback and for clarifying the ~/plan/progress direction. That makes sense to me.
I agree that CLIM should align with the progress-first model. In this framing, CLIM is better described as a progress-integrity evidence provider rather than a delay publisher.

1. Integration path: ~/plan/progress/error
   I agree that your second option seems like the better fit:

~/plan/progress/error
PlanError.msg
Error::code
Error::parameters as JSON

This keeps ~/plan/progress as the primary positive statement of confirmed progress, while allowing CLIM to provide structured, machine-readable cautionary signals through Error::parameters .
For example, CommandExecutionIntegrity could be represented by a dedicated CODE_ constant, with the CLIM payload stored as JSON parameters:

{
  "codeName": "CODE_EXECUTION_INTEGRITY_DEGRADED",
  "parametersSchema": "clim.command_execution_integrity.v0",
  "parameters": {
    "residual": 5.391,
    "causalAlignment": "BROKEN",
    "latencyClass": "CRITICAL",
    "executionState": "RESYNCING",
    "dominantCause": "PHASE",
    "recommendedProgressPolicy": "HOLD_PROGRESS_CONFIRMATION"
  }
}

CLIM would not publish the RMF message directly in the PoC. The robot adapter or Plan Executor would decide whether to convert this advisory into a real PlanError .
A similar JSON-parameter approach could also make it easier to bridge CLIM evidence into VDA 5050-style state/error reporting later.

2. EvidenceWindow
   The EvidenceWindow is intended to be a frozen causal evidence window captured around the moment of execution-integrity degradation. It is more than a log line, although logging is one of its uses. Its intended roles are:

• Progress supervision：It gives the progress supervisor evidence that the current progress estimate may need to be withheld, qualified, or recalculated.
• Operational diagnosis: It helps distinguish between physical blockage, stale command bursts, network timing collapse, feedback lag, command-feedback phase mismatch, or vendor driver execution issues.
• Multi-vendor debugging：In heterogeneous deployments, it provides a neutral execution record of which command-feedback window degraded, rather than only reporting that “the robot was delayed”.
  So I see EvidenceWindow as a small causal black box for the execution episode, not only a logging artifact.

3. Placement
   I fully agree with your instinct that CLIM should run on-board the robot platform, most likely inside or next to the robot adapter.
   That placement gives CLIM access to the freshest command stream, odometry, controller state, and vendor-driver feedback under the most consistent time base.
   The fleet layer should not be responsible for detecting these phase breaks after the fact. The robot should report them as execution-integrity evidence.
   I will update the PoC and README to reflect this alignment:

Primary RMF alignment:
  ~/plan/progress

Optional integration:
  ~/plan/progress/error using PlanError + Error::parameters JSON

CLIM role:
  robot-side progress-integrity evidence provider

Thanks again for the guidance. This gives me a much clearer integration path for the next iteration.

One additional point I should clarify: I see CLIM as algorithm-agnostic.

It does not need to know whether the robot is using Nav2, a proprietary navigation stack, or a custom controller. Different robots may fail differently under network or execution uncertainty: one may stop, another may rotate in place, another may replay buffered commands.

CLIM does not try to standardize those internal navigation behaviors.

It only checks whether the command stream, feedback stream, timing window, and physical response are still causally aligned. That gives heterogeneous fleets a common execution-health signal even when their internal autonomy stacks and failure modes are different.