Common BQL Model Implementation Failures

Why BQL Implementation Needs Its Own Checks

A censored-data likelihood can be specified correctly on paper and still be implemented incorrectly. A single branching error can assign a density to a below-quantification (BQL) record, use an LLOQ on the wrong scale, or count the same record twice. These errors can produce plausible-looking objective-function values while changing the estimates and their uncertainty.

The aim here is not to select a BQL method, but to verify that code implements the stated likelihood. The checks apply to the M3 likelihood and to other implementations that represent a BQL observation by the probability of falling below its applicable limit. They complement, rather than replace, the earlier material on stable computation of censored likelihoods, marginalization over random effects, and sensitivity analysis.

This distinction follows from what the record tells us. A quantified value identifies a measured value, so its likelihood contribution is a density at that value. A BQL result does not report an exact concentration; it reports that the concentration lies below a threshold, so its contribution is a probability over that interval. For a continuous distribution, using \(Y\leq L\) instead of \(Y<L\) gives the same probability.

The record-level formulas assume that the model distribution and its parameters are the ones intended for that observation, that the LLOQ is expressed in the same concentration units as the modeled observation (or transformed consistently), and that each measurement is represented once. When observations are conditionally independent, their record-level contributions multiply; subject-level random effects may require the appropriate integration over those effects. These checks do not authorize changing the model or its conditioning structure.

Establish the Correct Branch Before Checking the Arithmetic

For each record, first identify its status and the model scale. Then check the single contribution assigned to it. A quantified observation should reach the density branch; a BQL observation should reach the cumulative-probability branch. The measured concentration field for a BQL record may be missing or may contain a sentinel value, but neither circumstance turns the record into a quantified observation.

Check LLOQs on the Model Scale

An LLOQ is reported in the assay's concentration units, but the residual-error distribution may be defined on a transformed scale. A correct implementation applies the distribution function to a threshold transformed in the same way as the modeled random variable. For example, if \(Z=\log(Y)\) is normally distributed, then \(Y<L\) is equivalent to \(Z<\log(L)\). Using \(L\) itself as the threshold for \(Z\) is a scale error.

Detect Duplicate Contributions and Verify Record Counts

A BQL record should not enter both the censored branch and a generic quantified-observation branch. This often happens when a BQL record is retained with a sentinel concentration, and a second section of code processes every nonmissing concentration as quantified. A record-level audit should therefore verify not only the value of a contribution but also how many contributions each input row creates.

Build Small Tests That Fail Loudly

A large model fit is a poor first test of a new BQL implementation. On a tiny, fixed dataset, the expected branches and values can be calculated independently. Compare likelihood contributions before summing them into a subject or dataset objective; an aggregate can conceal a missing or duplicated record.

• One quantified record: check that the code evaluates \(f(y)\), not \(F(y)\), and that the density has the expected units.
• One BQL record: check that the code evaluates \(F(L)\), returns a probability between zero and one, and does not use a sentinel as an exact value.
• Two distinct records: include one quantified and one BQL record and verify that the joint contribution is the product of their individual contributions under the stated conditional-independence assumption.
• Two assay limits: give records different LLOQs and verify that each BQL record uses its own limit, converted to the model scale as necessary.
• Boundary and unit tests: check that increasing \(L\) cannot decrease \(F(L)\), and that changing concentration units while converting both observations and LLOQs consistently leaves standardized probabilities unchanged.

For the normal example above, the monotonicity check has a direct interpretation: a larger threshold includes more of the distribution below it, so \(F(L)\) cannot decrease as \(L\) increases. If code violates this property, investigate the sign of the standardized residual, the selected cumulative distribution function, and the scale conversion. Also check records near the limit, missing-value handling, and the data flags that route observations into the likelihood.

A test suite should compare both likelihood-scale and log-likelihood-scale results where practical. A probability can be rounded to zero in ordinary arithmetic for an extreme tail; stable log-CDF calculations address that numerical issue, but they cannot correct a wrong branch or threshold. Numerical stability and correct model logic are separate checks.

How These Checks Relate to Alternative BQL Approaches

Different BQL approaches encode different assumptions and therefore need different test expectations. The M3 approach uses the probability below the limit for a BQL record and the density for a quantified record. An M4 approach uses a different treatment of BQL records; its implementation should be checked against the specific M4 formulation chosen, not judged by expecting an M3 contribution. Deletion or substitution methods likewise define different analyses and do not become equivalent to a censored likelihood merely because their code runs successfully.

The most useful common checks are structural: confirm which records are included, which limits apply, how the model scale is handled, and whether the implemented likelihood matches the stated method. Predicted BQL frequencies and simulation checks can reveal broader mismatches between model and data, but a plausible aggregate frequency does not prove that each record has the correct contribution. This tutorial's unit tests target that narrower implementation question.

Common Mistakes and Limitations

• Using \(f(L)\) for a BQL record. A BQL result reports an event below a limit, not an exact value at that limit. Use \(F(L)\).
• Putting a concentration LLOQ into a log-scale formula unchanged. Transform the threshold consistently with the modeled variable; for a log-concentration model, use \(\log(L)\).
• Processing a BQL row twice. Verify one contribution per record, not merely the total number of rows in the input file.
• Assuming every product is a duplicate. A probability and a density can properly multiply when they represent distinct observations and the model's factorization justifies it.
• Treating a passing numerical test as model validation. A test verifies code against a specified likelihood. It does not establish that the residual distribution, censoring mechanism, or random-effects assumptions are appropriate.

Implementation checks also depend on the data contract. If assay limits vary, the input must preserve the correct limit per record. If records are transformed or units are changed upstream, the status, observation, and limit must remain aligned. A coding check cannot recover information lost or misclassified during data preparation.