Jam Yanh

The queue bug is the part I'd love more detail on. What changed in the job-claiming step to stop two workers from reserving the same job? A small before-and-after example would be useful.

A supersedes link plus an effective date makes sense. I'd scope both decisions to the same project: choosing Postgres for a new service shouldn't silently retire a SQLite choice elsewhere. Two retrieval tests would help: 'what applies now?' and 'what applied on this date?' Both should return the supporting record.

A worked example of a reversed decision would help explain the pyramid. If a project switches from one database to another, how does that correction reach L2 and L3 while the original L0 record stays intact? Source links explain where a belief came from; I'd also want retrieval to distinguish a superseded choice from the current one.

Thanks for adding the table, Oleg. Comparing the 0.90 and 0.95 rows makes the tradeoff much clearer: the extra precision comes with substantially fewer retained detections. That is much more useful for choosing a threshold than the ECE number alone.

Thanks, the distinction between yielding to a new task and only flushing microtasks is especially helpful. For an image-processing example, measuring cancellation delay alongside total processing time would make the chunk-size tradeoff easier to see.

The request-ID example is useful. A cancellation example would be a nice follow-up: in an image tool, a user might choose a second file while the first is still being processed. How would you stop that first job without terminating the worker and losing its other pending jobs?

Keeping the same 10,893 detections before and after correction makes the result much easier to interpret. Would you consider adding precision and retained-detection counts at a few thresholds on the corrected scores? That would help readers choose an operating threshold without confusing better calibration with improved recall.