Why this exists

Latency discussions are dominated by intuition, confidence and post hoc profiling. By the time a real system can be measured, the decisions about concurrency, feedback, sequencing and delay have already hardened and are expensive to undo. Profilers explain where the time went in a running system; they rarely explain why the user waited.

LatencyLab moves the question to design time. You write an explicit model (tasks, events, queues, delays, resource contention: everything named, nothing inferred) and the engine executes it with deterministic scheduling and seeded randomness, thousands of times. Out come concrete critical paths that name the work, queue-wait figures and percentiles split between UI events and overall makespan, because those answer different questions. When numbers change it is because the model changed, never because the measurement drifted.

The results routinely betray intuition. In the shipped music-discovery ingest model most people predict the background work dominates perceived latency; instead the smooth-feeling progress updates competing for one UI thread quietly extend the critical path. The same engine is one of the two instruments behind Relativistic Decision Architecture: it produced the book's hierarchy-depth and authority-placement numbers from published models and seeds, so every quantitative claim there can be rerun.

What works now is a local Python CLI reading a JSON execution model, with a desktop UI as a client of the same headless core and plain-file outputs you can plot or diff. Fully keyboard navigable, 100% coverage gated, no account, no server and nothing leaving your machine. It does not tune code and it does not reassure; it exists so the latency problem is found before it is politically expensive.

Full reasoning at crankthecode.com.