2.6 Measurement Models: How Much, and Against What Bound?
Quantitative engineering begins by deciding which quantities matter and how they relate. Raw telemetry is not yet a model. A pile of request logs and token counts becomes a measurement model only when an engineer names the quantities worth relating and the bounds worth comparing against.
DocAble's use of generative AI makes this concrete. A production job may consume a variable amount of model capacity and incur variable cost. The system therefore represents several related quantities rather than treating individual API calls as isolated events.
MODEL CARDGenAI cost and capacity · Measurement
- Engineering question — How much capacity is this workload consuming, what does a unit of work cost, and how close is demand to an operating or budget envelope?
- Model — a small web of related quantities: generation work induces usage and concurrency; usage and pricing determine cost, concurrency contributes to capacity demand, and both can be compared against operating or budget envelopes.
- Property — the quantities are relatable and comparable against a declared envelope, so demand can be read against a bound rather than watched call by call.
- Quality attribute — cost control, capacity planning, graceful behavior under load.
Figure 2.6-1 draws the model: generation work fans into usage and concurrency; usage and pricing determine cost, concurrency contributes to capacity demand, and both are read against operating or budget envelopes. It supports questions about capacity consumption, unit cost, active work, and proximity to operating or budget envelopes. These quantities come from concrete events — requests, token counts, leases, provider responses, and charges — but the measurement model gives those events engineering meaning by relating the quantities that matter.
The distinction matters because representing a threshold does not determine what happens when the threshold is crossed. In DocAble the same broad family of cost and usage measurements supports several kinds of response. Some quantities are observed. Some feed adaptive throttling. Per-job exhaustion can lead to soft completion rather than outright failure. A hard daily budget gate also exists, but stays dormant unless configured. Those are different authority choices over related measurements.
For now, Part II needs only the representation. Figure 2.6-2 reduces it to its core shape: a measured quantity read as a current state against a reference envelope, and the comparison between them.
Measurement gives the most familiar form of tolerance. The reference bound defines acceptable quantitative variation, while the current value describes the realized system against that bound. The model still does not decide what consequence follows from crossing it. A latency measurement can be compared with a budget without implying whether the result should merely be reported, trigger adaptation, degrade service, or block admission. Part III takes up that authority decision.
The same relation also introduces a further engineering idea: margin. If the current value lies within the acceptable region, one can ask how far it remains from the boundary. For a scalar quantity such as latency or memory use, the answer may be straightforward. Many software obligations do not admit such a useful distance, so MAGE does not assume that margin can always be measured. Part III returns to the distinction between satisfying a tolerance and knowing how much room remains inside it.
Part III returns to this example and asks the authority question: when should a measured quantity merely inform, when should it adapt behavior, and when should it stop work? Figure 2.6-3 keeps the two decisions separate: Part II models the quantities and bounds; Part III decides what follows from them—observation, adaptation, soft degradation, or a hard gate that may remain dormant.
The next chapter leaves quantities for history: what an operation did to an artifact, and what evidence records it.