Chapter 1 — Calculus I
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 Rates in a SOC"]
N2["1.2 Slopes from data"]
N3["1.3 Areas as totals"]
N4["Practice note — Units and dashboards"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 Rates in a SOC"]
N2["1.2 Slopes from data"]
N3["1.3 Areas as totals"]
N4["Practice note — Units and dashboards"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 Rates in a SOC]
|
v
[1.2 Slopes from data]
|
v
[1.3 Areas as totals]
|
v
[Practice note — Units and dashboards]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) read rates of change in intelligence workloads; (2) interpret a derivative as "how fast is this growing now"; (3) approximate an area under a curve to total a workload; (4) avoid extrapolating a local slope too far.
1.1 Rates in a SOC
Indicators arrive in Lantern at a rate that changes during the day: low overnight, rising when partner communities in other time zones publish. If N(t) is the cumulative count of indicators received by hour t, its derivative N′(t) is the arrival rate. Engineers size parsers and enrichment workers for the peak of N′, not for the daily average, because queues form when instantaneous arrival exceeds service.
A feed that delivers most of its daily volume in two morning hours needs workers sized for those hours, even though the average looks gentle. Kofi plots the rate rather than the running total when he checks this, because a cumulative curve hides bursts inside its steady climb.
1.2 Slopes from data
Real data are discrete. A difference quotient — (N(t+1) − N(t)) / 1 hour — estimates the rate. Smoothing over several hours reduces noise but hides short bursts; the choice depends on whether you are planning capacity (use peaks) or reporting trends (smooth).
Kofi keeps two views of the same counts for that reason. The raw hourly differences go to the capacity review, where a single busy hour matters. A six-hour moving average goes into the monthly report, where readers want to know whether partner volume is growing. Each chart says which one it is. Missing hours are left as gaps rather than filled, because an invented value would distort both the peak and the trend.
1.3 Areas as totals
If r(t) is the rate of analyst-hours needed to triage alerts, the integral of r over a shift is the total effort. A trapezoid sum over hourly samples is accurate enough for staffing.
With samples every hour, the trapezoid rule averages each pair of neighbouring rates and multiplies by one hour. Summing those slices across an eight-hour shift gives the analyst-hours the shift must cover. If the result is eleven hours of work and three analysts are on shift, the plan has slack; if it is thirty, the team needs help or a narrower triage scope. The estimate is only as good as the samples, so a missing hour is marked, not guessed.
1.4 Limits of local slopes
A burst during a major campaign may show a steep slope. Projecting that slope a month ahead predicts absurd volumes. Derivatives describe now; models of cause are needed for forecasts.
Kofi saw this when a partner published a large backlog of old indicators in one afternoon. The hourly rate jumped tenfold, then fell back the next day. Had he sized Lantern from that afternoon's slope, BEN would have bought hardware for a load that never returned. A forecast needs an explanation of why volume changes, such as a new partner joining, and the slope only tells him that something changed.
Practice note — Units and dashboards
Lantern's dashboard once plotted the cumulative total where operators expected a rate, and the night shift read a calm flat line as a sudden spike when the axis rescaled. Kofi now labels every chart either 'per hour' or 'cumulative since 00:00 UTC', and the capacity review uses only rate charts.
Worked example
Kofi samples Lantern's cumulative indicator count at 08:00 (12,400), 09:00 (12,700) and 10:00 (13,300). The rate rose from 300 to 600 per hour. He sizes the parser for at least 600 per hour plus headroom, and notes that the jump coincided with a partner's morning bulletin — a scheduled, not structural, increase.
Synthetic case. Lantern's counts are invented for this chapter.
Errors and limits
Confusing the cumulative count with the rate leads to absurd capacity plans. Calculus here measures workloads; it does not predict adversaries.
Exercises
- EX001 — Hourly rate. Using Kofi's samples, compute the arrival rate between 09:00 and 10:00. Rubric: 3 = 600 per hour with method; 2 = number only; 1 = uses cumulative; 0 = none.
- EX002 — Peak or mean. Explain why parser capacity is sized for peak rate rather than daily mean. Rubric: 3 = queues form when arrival exceeds service; mean hides bursts; 2 = partial; 1 = mean is fine; 0 = none.
- EX003 — Trapezoid total. Analyst-hours needed are 2, 4 and 6 per hour at three consecutive hourly samples. Estimate total effort over those two hours. Rubric: 3 = 8 analyst-hours via trapezoids; 2 = method right; 1 = sums to 12; 0 = none.
Synthesis
Rates size systems, areas total effort, and local slopes must not be stretched into forecasts.