sim_calibrate

Calibrate a model against YOUR event log — the reading that meets reality. Upload CSV (case_id, activity, timestamp; the shape sim_dataset emits, activities = transition ids), and rates are learned from the observed timings: sources from inter-arrival times, services from the gap before their completions, all per hour. Instant-pickup transitions (declared rate >= 100) keep their declared rate — their observed gap is the queue wait, and learning it would destroy the calibration discipline. A transition declaring a delay (a fixed-duration timer, not a rate) is fit differently and returned in learnedDelays instead of learnedRates: the MEDIAN observed gap, in hours, written onto the transition itself since a delay has no solver-map slot — a gapCV in rateEvidence far from 0 means the log looks exponential, not fixed, and the calibration says so in a caveat rather than trusting the median anyway. Returns a NEW content-addressed model (learned rates in the solver map, learned delays on the transitions, declared values otherwise untouched, lineage recorded) plus a conformance report: fittingPercent (full replays) is the headline, worst traces named with the activities that could not fire. tokenFitness is a second, harsher reading of the same replay (raw tokens present vs. required at every step, not full-trace success) that under-reads any net with a resource pool — read fittingPercent, not tokenFitness, unless you specifically want the raw-token number. Every learned rate or delay has an entry in rateEvidence: n (gaps it rests on), gapCV (sample std dev over mean of those gaps; ~1 for exponential timings, near 0 for a true timer) and insufficient when n < 2 — n=0 yields nothing, n=1 a value with no spread. Learned values on a structure that cannot replay the traces would be numerology — read fittingPercent before trusting them.