## Chapter 01 — Calculus I ### Learning outcomes and connection After this chapter you can (1) describe an incident queue as functions of time with explicit units; (2) use the derivative of the backlog to tell whether a response service is gaining or losing ground; (3) compute the sensitivity of a recovery estimate to its inputs; and (4) say where a smooth derivative misrepresents a queue of discrete cases. It prepares Chapter 6 (accumulation), Chapter 32 (reliability) and Chapter 36 (pipeline capacity). ### 1.1 Why an engineer of response systems needs rates A response service is a machine that turns arriving work — alerts, reports, cases — into decisions. Whether it keeps up is a question about *rates*. Let $\lambda(t)$ be the arrival rate in cases per hour and $\mu$ the rate at which the team can close cases. If $Q(t)$ is the backlog, then, treated as a continuous quantity, $$\frac{dQ}{dt} = \lambda(t) - \mu \quad \text{while } Q > 0,$$ and $dQ/dt = \max(0, \lambda - \mu)$ when the queue is empty. The sign of the derivative is the most important operational fact: positive means the backlog grows no matter how hard people work at the current capacity. Units keep you honest: $\lambda$ and $\mu$ are cases/hour, so $dQ/dt$ is cases/hour and $Q$ is cases. A design document that mixes "alerts per day" with "analyst hours" without a conversion is already wrong. ### 1.2 Derivative, rate and sensitivity The derivative $f'(t)$ is the instantaneous rate of change; on a sampled series you estimate it with a difference quotient $(f(t+h)-f(t))/h$. A *sensitivity* is a derivative with respect to a parameter instead of time. If the time to drain a backlog $Q_0$ at net rate $\mu - \lambda$ is $T = Q_0/(\mu - \lambda)$, then $$\frac{\partial T}{\partial \mu} = -\frac{Q_0}{(\mu-\lambda)^2}.$$ The square in the denominator is the engineering message: when capacity is only slightly above demand, a small loss of capacity — one analyst off sick — multiplies recovery time. Queueing theory reaches the same conclusion for waiting times as utilisation approaches one; [Little (1961)](https://doi.org/10.1287/opre.9.3.383) gives the identity $L = \lambda W$ relating average number in system, arrival rate and time in system that we use in Chapter 36. ### 1.3 Worked example (synthetic): an outage surge at Harrow Valley Shared Services Harrow Valley Shared Services (HVSS) is a **synthetic** public-service organisation used throughout this book. Its response desk closes $\mu = 12$ cases/h. Normal arrivals follow a daily cycle, $8 + 3\sin(2\pi t/24)$ cases/h. A service outage from $t = 2$ h to $t = 6$ h adds 14 cases/h of user reports and alerts. Lab 1 integrates the backlog in steps of 0.1 h. ```python """Lab 1 (synthetic): incident-queue backlog during an outage. Euler integration, step 0.1 h.""" import math MU = 12.0 # analyst capacity, cases/hour (synthetic) def lam(t): # arrival rate, cases/hour; outage surge 2 h..6 h base = 8 + 3 * math.sin(2 * math.pi * t / 24) return base + (14 if 2 <= t < 6 else 0) dt, q, t, peak, peak_t, wait_area = 0.1, 0.0, 0.0, 0.0, 0.0, 0.0 rows = [] while t < 12 - 1e-9: dq = lam(t) - MU q = max(0.0, q + dq * dt) wait_area += q * dt t = round(t + dt, 10) if q > peak: peak, peak_t = q, t if abs(t - round(t)) < 1e-9 and int(round(t)) % 2 == 0: rows.append((int(round(t)), lam(t - dt), q)) for h, l, b in rows: print(f"t={h:2d}h lambda={l:5.2f}/h backlog={b:6.2f}") print(f"peak backlog {peak:.2f} cases at t={peak_t:.1f}h") print(f"case-hours waiting (area under backlog) {wait_area:.1f}") print(f"derivative of backlog at t=3h: {lam(3)-MU:.2f} cases/h") ``` Expected output: ```text t= 2h lambda= 9.43/h backlog= 0.00 t= 4h lambda=24.56/h backlog= 24.14 t= 6h lambda=25.00/h backlog= 49.85 t= 8h lambda=10.64/h backlog= 47.60 t=10h lambda= 9.57/h backlog= 43.85 t=12h lambda= 8.08/h backlog= 37.46 peak backlog 49.85 cases at t=6.0h case-hours waiting (area under backlog) 370.7 derivative of backlog at t=3h: 12.12 cases/h ``` Read it as an engineer. At $t = 3$ h the backlog grows at about 12 cases per hour: during the surge, every hour adds roughly an hour of work. After the surge ends at 6 h, arrivals fall but stay near 9–11 cases/h, so the net drain rate is only 1–4 cases/h; twelve hours after the outage began, 37 cases are still waiting. The 371 case-hours of waiting is the accumulated delay that Chapter 6 teaches you to compute by integration. ### 1.4 Where a derivative misleads Cases are discrete, arrive in bursts and are not interchangeable: one ransomware case may consume more effort than forty phishing reports. The continuous model also ignores that people triage, merge duplicates and defer low-severity work — so the model overstates the backlog of *important* work and understates the backlog of trivial work. A difference quotient on noisy hourly counts amplifies noise; smooth before you differentiate, and report the window used. Finally, $\mu$ is not constant: fatigue, handovers and context switching reduce it exactly when the surge is worst. ### 1.5 Common errors and limits - Mixing units (per day vs per hour) in the same equation. - Treating capacity as fixed during a long incident. - Reporting a single "time to clear" without its sensitivity to capacity. - Differentiating raw counts without smoothing or stating the step size. Each error shows up in the HVSS surge of Lab 1. A planner who reads 12 cases/h as 288 per day and compares it with an hourly outage peak of 25 arrivals will mistake a twelve-hour backlog for a momentary blip. The 37 cases still waiting at t = 12 h assume that all twelve hours of capacity were delivered, which tired analysts on a long shift rarely achieve. Quote that figure with its sensitivity to capacity, and state the 0.1 h step the lab used. ### Exercises — chapter 01 **EX001 — Drain time sensitivity.** *Objective:* quantify how fragile a recovery estimate is. *Inputs:* backlog $Q_0 = 50$ cases, arrivals $\lambda = 10$ cases/h, capacity $\mu = 12$ cases/h. *Steps:* compute $T$; compute $\partial T/\partial \mu$; estimate $T$ if one of six analysts is lost (capacity falls proportionally). *Expected evidence:* three numbers with units and one sentence of interpretation. *Rubric:* 3 = all correct with interpretation; 2 = one error; 1 = formula only; 0 = none. **EX002 — Reading Lab 1.** *Objective:* connect the model to a staffing decision. *Inputs:* Lab 1. *Steps:* change the outage surge to 7 h duration (2–9 h) in the code and record the peak backlog and its time; state one reason the real peak would differ. *Expected evidence:* modified line, two numbers, one limitation. *Rubric:* 3 = correct run and a substantive limitation; 2 = run only; 1 = attempt; 0 = none. ### Chapter synthesis The backlog derivative $\lambda - \mu$ tells you whether a response service is winning. Sensitivities show how close-to-capacity operation turns small losses into long delays. Use the continuous model to reason, then check its assumptions against the discrete, bursty and uneven reality of cases. ### Continue studying — chapter 01 of 50 [← Course home](../../README.md) · [Course chapter index](../SUBJECTS.md) · [Chapter 02 →](#ch-02) Continue to the next authored lesson. ## Worked answers **EX001.** $T = Q_0/(\mu-\lambda) = 50/(12-10) = 25$ h. $\partial T/\partial\mu = -Q_0/(\mu-\lambda)^2 = -50/4 = -12.5$ h per (case/h): each case/hour of lost capacity adds about 12.5 hours near this operating point. Losing one of six analysts reduces capacity to $12 \times 5/6 = 10$ cases/h $= \lambda$, so the net drain rate is zero and the backlog never clears (it random-walks in reality). Interpretation: the service operates so close to capacity that the published recovery estimate is meaningless without a staffing assumption; the design needs surge capacity or deferral rules. **EX002.** Change `2 <= t < 6` to `2 <= t < 9`. Output: peak backlog 87.99 cases at $t = 9.0$ h; 561.8 case-hours of waiting over 12 h. Limitations (any one, substantively argued): duplicate user reports about the same outage would be merged, so the true backlog of distinct work is smaller; capacity falls with fatigue in a seven-hour surge; severity mix changes during an outage.