Cut-off parameter for the Reverse Monte Carlo method

Hello,
I have been writing simulation to calculate TID for space application. I used the Reverse Monte Carlo method to do it. My code is based on the example \extended\biasing\ReverseMC01. I noticed that for small values of the cut-off parameter (e.g. 0.0001 mm) the TID value can be even five times greater than for default one (1 mm). E. g. TID ~ 3 Gy(Si) for 1 mm of cut-off parameter, TID ~ 6 Gy(Si) for 0.001 mm and 15 Gy (Si) for 0.0001 mm.
Is it a known problem or bug for the Reverse Monte Carlo method or is it normal behavior?
I found a similar problem in the presentation summary https://indico.esa.int/event/249/contributions/4179/attachments/3264/4237/RMC_G4SUW_2018.pdf
(Bug related to the physics “Cut off” identified).
I have been analyzing the CubeSat model on LEO orbit,
I use the newest version of Geant 4.10.05_p01,
I generated GPS from SPENVIS software.
A detector is a 0.1 mm diameter sphere made from silicon.

I also analyzed the same model with slab detector (50x50x0.1 mm) but using the forward Monte Carlo method to compare results. For the forward Monte Carlo method, I do not have such discrepancy for a different cut-off parameter.

I run the example \extended\biasing\ReverseMC01 for “run_adjoint_simulation_protom.mac” macro file with paramiters as follow

#Define some geometrical parameters
###############################################
/RMC01/geometry/SetSensitiveVolumeHeight 0.01 mm
/RMC01/geometry/SetSensitiveVolumeRadius 0.01 mm
/RMC01/geometry/SetShieldingThickness 3. mm

#Select physics list
###############################################
/adjoint_physics/UseProtonIonisation true
/adjoint_physics/UseGammaConversion false
/adjoint_physics/SetEminForAdjointModels 1. keV
/adjoint_physics/SetEmaxForAdjointModels 400. MeV

and cut-off parametes /run/setCut 1 mm, /run/setCut 0.001 mm, /run/setCut 0.0001 mm.

The energy deposited for cut-off parameter equals 0.0001 mm is over three times greater than for default one. For the forward Monte Carlo simulation, there is no such discrepancy!

Thanks,
Szymon