Probabilistic decisioning for pharma — Monte Carlo, Bayesian and Arrhenius in QA, transport and negotiation

1. Executive summary

Pharmaceutical operational decisions — releasing a batch after a temperature excursion, scoring tender coverage, framing a counter-offer to a supplier price claim — are routinely framed as if they had single right answers. They do not. The underlying reality is always probabilistic: a distribution of shelf-life loss given the time-temperature profile, a distribution of award probability given the lane history, a distribution of supplier acceptance given the BATNA.

This paper argues for replacing the deterministic decision-support paradigm with a probabilistic one that surfaces distributions and confidence intervals as first-class outputs. We walk through three mathematical foundations — Monte Carlo simulation, Bayesian inference and Arrhenius kinetics — and demonstrate each with a worked pharma operational example.

2. The problem — point estimates in a probabilistic world

Consider a typical scenario. A cold-chain shipment of an active pharmaceutical ingredient (API) experiences a 6-hour excursion above 8°C, peaking at 14°C. The QA team needs to decide: release the batch or reject. The classical decision-support tools — typically Excel with a stability-data lookup, or a fixed-rule QMS workflow — return a single answer: "release" or "reject", optionally with a single estimated shelf-life loss number (e.g., "11 days").

This framing is operationally convenient but epistemologically wrong. The actual shelf-life loss is not a single number but a distribution shaped by:

• Activation energy (E_a) uncertainty — typically known to ±15-20% from stability studies, but rarely communicated as a distribution.
• Sensor calibration error — modern data loggers are accurate to ±0.5°C at room temperature but drift over deployment.
• Spatial inhomogeneity — the sensor is one point in the pallet; the actual product experienced a range of temperatures.
• API-specific Arrhenius parameters — sometimes extrapolated from chemically similar compounds rather than directly measured.

When the QA team is asked six months later — by an auditor or by the supplier of a returned batch — "why did you release this?", the documented rationale must address all of these. Saying "the Excel model said shelf-life loss was 11 days, below the 30-day threshold" is not a defensible answer. Saying "the calibrated distribution placed shelf-life loss at 11 days ± 4 days (95% CI), with 3% probability of exceeding 30 days, which our risk policy classifies as acceptable for this batch class" is.

The same pattern repeats across operational pharma decisions. The cost of using point estimates is not always visible: a tender awarded to a carrier with a quietly elevated tail risk; a counter-offer that the supplier rejects because the BATNA was unrealistic; a borderline batch released because the decision tool reported "OK" without showing the distribution.

3. Three mathematical foundations

A probabilistic decision engine for pharma operations rests on three foundations, each appropriate to a different class of question.

Monte Carlo simulation

Used when the question is "what is the distribution of outcomes given many uncertain inputs". Repeatedly sample input distributions, compute the outcome each time, accumulate the empirical output distribution. Computationally inexpensive in modern hardware; suitable for tender coverage scoring, lane risk forecasting, capacity stress-tests.

Bayesian inference

Used when there is a prior estimate that should be updated as new evidence arrives. The classical pharma application is supplier price-elasticity: the prior is based on category benchmarks (Fastmarkets, ICIS, LME), the likelihood comes from the supplier's actual responses to past offers, the posterior is the elasticity distribution we should use to plan the next round.

Arrhenius kinetics

The empirical rate law of chemical degradation as a function of temperature, used to translate time-temperature profiles into shelf-life loss estimates. The Arrhenius equation is deterministic in form but probabilistic in application — the parameters (A, E_a) are themselves estimates with confidence intervals from stability studies.

4. Worked example 1: Arrhenius kinetics in QA shelf-life modelling

The Arrhenius equation describes the rate constant k of a chemical reaction (in this case, degradation of an API) as a function of temperature:

For a temperature excursion event, the operational question is: given the actual time-temperature profile from the sensor log, what is the effective shelf-life loss compared to a hypothetical isothermal storage at the labelled condition?

The probabilistic engine computes:

1. Cumulative exposure — integrate k(T) over the actual profile to obtain the equivalent isothermal exposure time at the reference temperature.
2. Shelf-life loss distribution — translate exposure into days of shelf-life consumed, propagating uncertainty in E_a, A and sensor calibration through the calculation. Monte Carlo with 10,000 samples typically converges within seconds.
3. Threshold probability — given the customer's rejection threshold (e.g., 30 days), compute the probability that shelf-life loss exceeds it.

Output is not "shelf-life reduced by 11 days" but "shelf-life loss is 11 ± 4 days (95% CI), with 2.7% probability of exceeding the 30-day rejection threshold". The decision policy layer then maps this to a recommendation — release, hold for QP review, or reject — depending on the batch class and the customer's risk tolerance.

The benefit is most visible six months later, when an auditor asks "why was this batch released given the excursion". The reproducible decision package contains the input profile, the calibrated Arrhenius parameters, the resulting distribution, the threshold check and the policy version. The decision is reproducible bit-for-bit.

5. Worked example 2: Bayesian inference in supplier price elasticity

Supplier negotiation is the classical setting for Bayesian inference: we have a prior estimate of the supplier's price elasticity (from category benchmarks), we observe their response to a given offer, we update.

The Bayesian update for elasticity (let's call it e) is:

After 3-5 rounds with a supplier, the posterior typically converges to a tight distribution that lets us frame the next counter-offer with calibrated expected-acceptance probability. The Decision Hub then recommends four price chips — Requested, Target, Ceiling, Walk-away — with their respective acceptance probabilities.

The negotiator decides which to send. The Decision Hub does not claim that any single number is "best" — it shows the trade-off curve between expected savings and risk of supplier walk-away, and lets the negotiator apply judgment with full context.

6. Worked example 3: Monte Carlo for tender coverage scoring

Question: given the production plan for the next quarter and the active tender lanes, what is the probability that we cover 95% of transport demand without spot freight exposure?

Monte Carlo handles this naturally. Sample from:

• Production plan stochasticity — slip probability per SKU per week, historically calibrated.
• Carrier acceptance per lane — historical award acceptance rate for each active tender carrier.
• Demand volatility per temperature class — cold-chain and ambient have different variability profiles.
• Spot rate inflation distribution — by carrier and month, from historical spot vs contract rate spreads.

Run 10,000 simulations. The output is a distribution over the joint outcome "coverage rate × total spot exposure cost". The engine then identifies the lanes contributing most to the tail risk (worst 5% of outcomes) and recommends a mini-tender for those lanes before invoices reconcile.

Operationally, this turns the planner's "I think we're mostly covered" into "we're 87% likely to cover 95%+ of demand, with tail risk concentrated in three lanes; running a mini-tender for those lanes brings the joint probability to 96%".

7. Auditability — model versions in every decision

The auditability story is what separates probabilistic decisioning from probabilistic curiosity. Every decision package output by a properly-engineered probabilistic engine must include:

• The engine version (semver) — so the exact mathematical implementation can be replayed.
• The parameter set version (per-tenant) — your specific Arrhenius parameters, your specific carrier history, your specific supplier elasticity priors.
• The rule set version (your SOPs) — the hard gates that ran before the probabilistic layer.
• The policy layer version — your specific risk tolerance configuration.
• The input data lineage hash — what raw data fed this decision.
• The SHA-256 hash of the full PDF + JSON output — for tamper-evidence.

When an auditor asks "why did the model recommend X two years ago?" — the team replays the exact engine version with the exact same inputs and obtains the exact same output. Bit-for-bit reproducibility is the operational requirement, not a nice-to-have.

8. What probabilistic decisioning is NOT

• Not a large-language-model. LLMs may have a role in parsing free-text excursion notes into structured fields, but they do not enter the decision recommendation loop. Probability distributions come from explicit mathematical models, not from text-generation token sampling.
• Not a black box. Every distribution can be inspected, every rule is human-readable code, every recommendation traces back to its inputs. If the engine recommends X and the operator disagrees, the engine's reasoning is reviewable in full.
• Not a replacement for QA / QP / procurement judgment. Probabilistic decisioning recommends; humans approve. The approval is part of the decision package.
• Not magic. Output quality is bounded by input quality. The engine's role includes flagging when inputs are insufficient for confident inference — and refusing to recommend rather than confabulate.

9. Takeaways

1. Pharma operational decisions are probabilistic by nature; deterministic tools force a lossy framing on them.
2. Three foundations cover most operational decision classes: Monte Carlo (forecasting), Bayesian (sequential updating), Arrhenius (chemical kinetics).
3. The right architecture layers hard rules (SOPs / GxP) → probabilistic models → decision policy (risk tolerance), with explicit version stamps at each layer.
4. Auditability requires bit-for-bit reproducibility, not just logging — engine version, parameter version, rule version, policy version, input hash and output hash in every decision package.
5. Probabilistic does NOT mean opaque. Every distribution is inspectable, every recommendation is reviewable, no LLM is in the decision loop.