A plug is a number reverse-engineered to make an output land on a target and then presented as an assumption. For example, a model might show a $985,000 funding need while the desired raise is $900,000. An unexplained reduction entered solely to close that gap would conceal the underlying funding need. This example is illustrative.
A plausible value can still lack a defensible basis. Automated checks help a reviewer find inputs that deserve explanation, but they cannot determine intent or replace a review of the source.
The signal
Unusually precise hardcoded inputs can be worth checking. Goal Seek and similar tools can produce long decimal tails, but so can legitimate unit conversions, weighted averages and imported calculations. Precision alone does not establish that a value was reverse-engineered.
Ask how the number was calculated, what evidence supports it, and whether it changes appropriately when the underlying assumptions change.
EXHIBIT 1 · TWO ILLUSTRATIVE INPUTS
The three checks
The detector flags unusually precise hardcoded values, adjustment labels and embedded constants for review, reporting the sheet, cell and reason for each flag.
- Unusually precise inputs. Hardcoded values with seven or more decimal places are a screening convention here, not proof of a plug. Check the calculation or source before changing them.
- Adjustment labels. Review non-round hardcoded values near labels such as reduction, adjustment, haircut, true-up, gross-up or factor. These can be legitimate; the question is whether their basis is documented.
- Embedded constants. Review hardcoded scaling ratios inside formulas. A governing assumption is usually easier to inspect and maintain as a labeled input, while ordinary mathematical constants need no such treatment.
Each flag needs a source, an explanation or a correction before delivery. A documented false positive is not a model error.
The second question
Detecting plugs asks whether a number was chosen. A second and harder question asks whether a number does anything.
A model can pass every plug test, every balance check, and every tie-out while being mechanically inert. Five patterns deserve review; some are deliberate design choices that need clear documentation.
- Dead inputs. A hardcoded number on an input sheet that no formula anywhere reads. It looks editable and drives nothing, so a user changes it, sees no movement, and draws a conclusion about the business from a cell that was never connected.
- Binary multipliers. A zero-or-one flag multiplied into a business flow can create a sharp discontinuity. Check whether it represents a physical limit, a contractual condition or an explicit management-policy scenario.
- Frozen exhibits. A worksheet whose name promises a sensitivity or a scenario sweep and whose contents are mostly hardcoded values. It shows an answer computed at some point in the past with nothing on the page saying so.
- Buried constants. A governing quantity hardcoded inside a formula. The user cannot find it, so the user cannot change it.
- Enumerated inputs. An input whose consumers only ever test it against specific literal values, so a cell that looks like a year is a two-position switch that falls to an error branch for any other entry.
Make decision rules explicit
Show policy thresholds separately from operating assumptions. If a scenario assumes hiring, spending or shutdown decisions at a threshold, make that rule explicit and compare it with the unconstrained case. Physical and contractual limits should also be visible and supported.
Sweep a contested driver across its plausible range and inspect the output. A discontinuity may reflect a real capacity limit or an agreed decision rule. An unexplained cliff deserves investigation.