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 CARD

GenAI cost and capacity · Measurement

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.

DocAble's GenAI cost-and-capacity measurement model: two separate envelopes Generation work splits into two independent quantity chains. One chain: usage relates to cost, which is compared against a cost budget. A separate chain: concurrency relates to capacity, which is compared against a capacity envelope. The two chains are drawn apart because they are distinct envelopes, not one shared budget. TWO ENVELOPES, NOT ONE generation work usage cost cost budget concurrency capacity capacity envelope Two chains, two envelopes — usage feeds a cost budget, concurrency feeds a capacity envelope; they are not one relation.
Figure 2.6-1. GenAI cost-and-capacity model. Generation work fans into usage and concurrency; usage and pricing determine cost against a budget, and concurrency contributes to capacity demand against a capacity envelope. The model names the quantities worth relating — the interpretation placed over raw requests and charges, not the telemetry itself.

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.

A current value is compared against a separately declared reference bound Two peer inputs — a current value and a reference bound — converge into a comparison. The reference bound is declared separately; it is not derived from the measured quantity. The model says what is compared, not what to do about the result. CURRENT VALUE what is now REFERENCE BOUND declared separately COMPARISON The bound is declared apart from the quantity. The model compares; it does not decide the consequence.
Figure 2.6-2. Core measurement relation. A current value is interpreted against a separately declared reference bound. The model defines what is compared; it does not determine the consequence of the comparison.

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.

One measurement, different authority decisions Part II, the model, names a quantity and a reference bound and compares them, answering what quantity and bound matter. Part III, the authority decision, takes the same model and chooses its force: observe, adapt, degrade, or gate. Observe and adapt are shown in gray; degrade and gate, the consequential decisions, in rust. Modeling and authority are separate moves over one shared model. One Measurement, Different Authority Decisions PART II · MODEL quantity bound comparison “What quantity and bound matter?” PART III · AUTHORITY DECISION same model observe adapt degrade gate “What consequence is justified?” The model defines the quantity and bound; Alignment decides whether to observe, adapt, degrade, or gate.
Figure 2.6-3. Modeling and authority are separate decisions. The measurement model defines the quantity and reference bound; Alignment determines whether the result is observed, used to adapt behavior, triggers graceful degradation, or carries gating authority.

The next chapter leaves quantities for history: what an operation did to an artifact, and what evidence records it.

© James C. Davis, 2026–present