In a multi-unit group, the decision to extend a pricing model that works in one business unit across the remaining units almost never opens as a contested item at the board table. It is, on the contrary, among the easiest approvals to obtain: the instrument already functions, the investment has been made, the team has been trained, and standardisation across the group is presented as a virtue in its own right. In the same meeting, the question of the conditions under which the instrument works is rarely put, and when it is put, the answer arrives in the form of performance output — margin improved by this much last year, dispersion narrowed by that much — rather than in the form of validity conditions. Approval is granted, a rollout calendar is set, and twelve months later, when it becomes apparent that the model is not producing the expected result in the second unit, the subject of discussion is no longer the model but that unit's implementation discipline.
The pattern is not confined to pricing. Maintenance planning logic developed at one manufacturing site is carried to a second site, a commission structure calibrated for one sales team is carried to a new channel, an investment approval matrix built at head office is carried into an acquired company, and a supplier scoring system tuned in one country operation is carried into another jurisdiction — each transfer resting on the same silent premise, namely that the validity of the instrument resides in the instrument rather than in the place where it is used. What moves is the formula, the weightings, the thresholds, the approval steps; what does not move is the condition set underlying that formula, recorded nowhere because, at the moment of design, it was simply ambient.
In the organisational psychology literature this tendency is named deployment bias — the use of a model in an organisational context other than the one for which it was designed, with its validity presumed intact — and its mechanism operates on two layers. The first layer is a representation problem: a model internalises the regularities of the environment in which it was built, and those regularities are encoded not in the model's parameters but in the surroundings that make the parameters meaningful. A maintenance plan presupposes the site's equipment age distribution, its shift structure, its spare-part lead times, and its technician turnover rate; none of these presuppositions appears in the plan document, because at the time of writing all of them were already present and therefore invisible. The second layer is an attribution problem: divergence produced by the instrument in the new setting is assigned to the competence of the implementer rather than to the boundary of the instrument's validity, and that assignment structurally forecloses any interrogation of the model.
It matters to see that this tendency is not an error. Carrying a functioning instrument rather than reinventing it is plainly rational where conditions are sufficiently similar; having each unit construct its own pricing logic from scratch destroys comparability at group level, raises the cost of oversight, and confines institutional memory within unit boundaries. Standardisation is an efficiency gain to the extent that contextual variance is low. The difficulty lies not in the shortcut itself but in the fact that the assumption sustaining the shortcut is never tested — that is, in the absence of any institutional procedure asking which conditions travelled with the model and which were left behind.
The institutional cost appears first, contrary to expectation, not in the model's output but in its input. The receiving unit populates identical field names according to the logic of its own operation: in the first unit "delivery date" is the date in the contract, while in the second it is the date of despatch from the warehouse; "active customer" denotes, on one side, a customer transacting within the last twelve months and, on the other, a customer with an open current account. The model continues to operate correctly in mathematical terms, generates output, is reported, and the divergence stays invisible for months, since no control point asks whether two fields bearing the same name are measuring the same event. By the time the divergence is finally noticed, retrospective correction is generally not undertaken, because it would reach back into pricing decisions taken, commissions calculated, and quotations issued during the period; the error is written off as a one-time cost and the model remains in use.
The second cost line accumulates along the incentive channel. A commission structure calibrated in one unit, once carried into a channel with a materially different sales cycle, produces not the same behaviour but whichever behaviour is most easily rewarded in that channel; a system whose payment threshold was set against a short cycle steers the representative in long-cycle business toward small and fast transactions, and the balance-sheet correlate of this is not a decline in revenue but the quiet erosion of average transaction size and customer lifetime value. That erosion is not visible in monthly reporting, since the aggregate revenue target is being met; it emerges some eighteen months later, when renewal rates in the same channel are questioned, and at that point the chain of causation can no longer be reconstructed.
The third cost, and the one connected most directly to the valuation table, appears when head-office models are carried into acquired companies. In a post-acquisition integration plan, converting the target's investment approval matrix to the group standard is a near-automatic step; yet the target's decision velocity is frequently part of the acquisition thesis itself — the company was bought precisely because it was small in scale, quick in decision, and close to its customers. The group approval matrix carries thresholds calibrated to a particular capital base and a particular risk appetite, and once those thresholds are applied to a smaller balance sheet, a substantial share of the target's routine operating decisions is escalated to the centre, the decision cycle lengthens, and the agility that formed the rationale for the acquisition is consumed by the integration itself. In a subsequent disposal process, a loss of this kind presents to the party conducting due diligence as a growth deceleration that resists explanation, and it depresses the multiple directly.
The mechanism that neutralises this tendency is neither individual attentiveness nor implementer training; neither addresses the problem at the correct layer, since the person carrying the model does not know the assumption that was left behind. The intervention that works has four separable components. The first is a validity-condition record, prepared not at the moment of transfer but at the moment of construction, setting out in writing the conditions under which the model was taken to hold — which volume range, which customer profile, which data latency, which distribution of decision authority. The second is a calibration test conducted inside the receiving unit: before the model enters production, it is run backwards against that unit's historical data and compared with the decisions actually taken. The third is a field-definition reconciliation, confirming field by field whether every input the model consumes measures the same event in both units. The fourth is a divergence threshold and a review rhythm: where model output falls outside a band derived from the historical distribution in the originating unit, the deviation is classified automatically as a validity question rather than an implementation failure and is referred for examination.
Working with groups that hold multiple assets and multiple operating contexts, BEIREK attaches every transferred decision instrument to a handover file that carries not the model but the ground of its validity. The file contains three things: the list of assumptions treated as true in the context where the instrument was built, a written assessment of whether each of those assumptions is satisfied in the receiving context, and, for every assumption that is not satisfied, a record either of the recalibration applied to the instrument's parameters or of the divergence knowingly accepted. An accepted divergence is itself a decision and is recorded as one, so that when performance is debated eighteen months later, the question of whether the outcome originated in implementation discipline or in a contextual difference acknowledged at the outset is put to a document rather than to recollection.
The operating rhythm of that file is tied to the calendar of the project or the integration: the assumption list is drawn up before the instrument is handed over, the retrospective calibration is run in the final stage before handover, output distribution is compared against the source context across the first two reporting periods after production release, and the validity conditions are revisited at the close of the first year. The principal function this rhythm carries is less the prevention of error than the correct classification of it, because the cost of failing to notice that a model is running in the wrong context is consistently higher than the cost of a model that was wrong from the beginning. A wrong model gets corrected; a correct model in the wrong context inspires confidence for years and, for exactly that reason, goes unexamined.
At an investment committee table, the presence of a single standard decision instrument across a group is frequently read as an indicator of institutional maturity, and under certain conditions it genuinely is one. The same finding, however, carries the opposite signal where no record exists of how the instrument was calibrated in each unit: decisions generated in materially different contexts come to look comparable simply because they sit behind a common formula. The question worth putting is not whether the group operates a single model, but whether the group knows, institutionally, in which context that model was built, into which contexts it has been carried, and what was left behind at each transfer. In a structure that can answer with documentation, standardisation is a lever; in a structure whose answer resides only in an implementer's memory, it is a source of variance whose cost has not yet been measured.