Good afternoon Pedro, thank you very much for the detailed reply.
Let me add a bit more context about my use case, because it may affect whether adjusting edge.speed is acceptable or not.
My final objective is emission prediction, where accuracy depends strongly on mean speed per edge, acceleration / stop-and-go patterns and time-loss reproduction. Even adjusting tau, sigma and speedFactor globally, the gap remains substantial in many urban edges, that's why we treated adjustments to edge.speed as an operational tool to close the calibration loop, ensuring that observed free-flow speeds are matched when behavioural parameters alone cannot achieve this because of the simplified model (default traffic lights, no behavioural heterogeneity, default vType, etc.). Also taking into account that the comparison between real and simulated traffic counts obtained is pretty accurate (92.7%) with flowrouter.
I understand your point about future scenarios, however, I do not plan to evaluate infrastructure upgrades, only emission baselines and short-term predictions. So I am trying to judge whether modifying edge.speed is an acceptable pragmatic solution in this context or something SUMO experts would still discourage, even for emission-focused applications.
For even further context, I am sharing the results of matching speeds before and after applying the algorithm. Before the algorithm (only blue dots), you can see the comparison between real speed (X axis) and simulated speed (Y axis), where the simulation shows a clear trend to real speed limits (20-30-50 km/h). After applying the algorithm, the accuracy for both the detectors used for calibration (blue dots) and the detectors used for validation (red dots) increases a lot.
Would you still recommend avoiding modifications to edge.speed, even if driver-parameter calibration alone cannot fully reproduce the observed speeds?
Thanks again for your guidance!
Gabriel