Cross-Scale Transfer Review¶

Cross-scale review — instantiates Dimensional Consistency Check

Rechecks whether a metric, rule, or equation that held at one scale still holds after it moves to another — and draws the boundary where its validity ends.

A number can be perfectly valid where it was measured and quietly wrong once it is carried somewhere else. Cross-Scale Transfer Review is the check you run at the moment of movement — pilot to rollout, one region to a whole market, lab bench to production plant, one population to another — asking whether the quantity's units, denominators, and scale meaning survive the trip. Its defining concern is not the calculation itself but its reach: where does this expression stop being true? Unlike a static unit check, it treats validity as bounded by the context a number was born in, and its central output is a transfer boundary — an explicit statement of the conditions under which a transferred result may be trusted and beyond which it must be re-derived.

Example¶

A subscription company runs a paid-acquisition test in one metro and gets a customer-acquisition cost of ≈$40. Finance wants to drop that straight into a national budget: total spend × (1 / $40) = new customers. The transfer review stops the copy-paste by asking what was scale-dependent in that $40. The test metro skewed young and urban, the ad channel had unsaturated inventory, and the figure was a blended average over a two-week window. At national scale the inventory saturates so marginal cost rises, the demographic mix shifts, and a two-week rate can't be treated as a steady state.

The output is not "the number is wrong" but a boundary: the $40 holds only up to roughly the test market's audience size and ad-inventory depth; past that, acquisition cost must be modeled as rising, not flat. The review also pushes the edge case — what happens where inventory runs out entirely — because that extreme is where a flat extrapolation breaks first. The correction is to re-derive acquisition cost as a curve, not to reuse a point.

How it works¶

Name what was scale-bound. List the quantities whose value depended on the original scale — saturating denominators, overheads that stop being fixed, averages taken over a window that won't recur.
Stress the extremes. Push the expression to the edges of the new scale (very large, very small, a denominator going to zero) and find where it first misbehaves; that edge usually marks the boundary.
Draw the boundary explicitly. State the range of scale, population, or time over which the result may be reused, and flag anything beyond it as requiring fresh derivation.
Decide reuse vs. re-derive. Past the boundary the correction is not a conversion factor but a rebuilt expression.

Tuning parameters¶

Boundary tightness — how conservatively the validity range is drawn. A tight boundary forces re-derivation sooner (safer, more work); a loose one reuses more (cheaper, riskier).
Scale dimensions checked — which axes of "scale" you test: size, population, geography, time horizon, unit system. More axes catch more failure modes but slow the review.
Edge-probe depth — how far toward the extremes you push before trusting the middle. Deeper probing surfaces nonlinearities a spot-check misses.
Re-derivation trigger — the mismatch size that flips a result from "reuse with a caveat" to "rebuild from scratch."

When it helps, and when it misleads¶

Its strength is catching the pilot-to-scale illusion, where a locally true number becomes a nationally false plan because nobody re-examined it at the moment it moved. It is the mechanism that turns "it worked in the pilot" into a bounded, checkable claim.

Its classic failure is assuming external validity by default — transferring a result because it is convenient and treating a bounded finding as a universal law.^[1] It can also draw the boundary too loosely to matter, or too tightly to be usable. The discipline that guards against the first is to make the transfer boundary a required output of the review rather than an afterthought, so no result crosses scales without one attached.

How it implements the components¶

transfer_boundary — its primary product: the explicit statement of where the transferred expression stays valid and where it does not.
consistency_test — the review itself is the consistency test, applied specifically at the point of transfer.
edge_case_quantity_check — probing the extremes of the new scale is how the boundary is located.
correction_rule — for anything past the boundary, the rule is re-derive rather than reuse.

It does not build the shared unit basis or convert quantities (that is Unit Conversion Workflow), nor design the comparable metric being moved (that is Normalized Metric Design); it only tests whether an existing expression survives the move.

Instantiates: Dimensional Consistency Check — this review is the archetype applied at the seam between one scale and the next.
Sibling mechanisms: Dimensionless Ratio Construction · Normalized Metric Design · Dimensional Analysis Table · Engineering Equation Sanity Check · Finance / Accounting Unit Check · Model Input / Output Contract · Per-Capita or Per-Unit Conversion · Spreadsheet Unit Audit · Stock / Flow Separation Check · Unit Check · Unit Conversion Workflow

Notes¶

A result is often made transferable in the first place by expressing it as a dimensionless group (see Dimensionless Ratio Construction); this review is the complementary act of checking a transfer after the fact. When a metric refuses to transfer cleanly, the fix is frequently to re-express it dimensionlessly rather than to keep patching conversion factors onto the raw form.

References¶

[1] External validity — the degree to which a result established in one setting, sample, or scale holds in another. A cross-scale transfer is an external-validity claim, which is why it should be stated with its boundary conditions rather than assumed. ↩