Covariate Selection Audit
How Licklider currently handles covariate-adjustment disclosure in multi-predictor linear regression, what triggers the check, what you must confirm before claim-bearing export, and where the current support boundary sits.
When a linear regression uses more than one predictor, the reported coefficient is no longer a simple one-variable relationship. The result reflects an adjusted model, and that adjustment needs to be disclosed before the output is treated as a claim-bearing result.
Licklider currently handles this as a covariate-adjustment disclosure check. It does not yet perform a full automated audit of how the predictor set was chosen, but it does detect when a multi-predictor linear regression includes covariate adjustment and asks you to resolve that disclosure before claim-bearing export is allowed.
What you get from this check
If this check is active, Licklider helps you avoid exporting a covariate-adjusted regression result without explicitly acknowledging that adjustment.
In practice, this gives you three things:
- A prompt in the figure review flow to resolve the covariate-adjustment disclosure
- A recorded summary of which response column and predictor columns were used in the adjusted regression
- An export decision that keeps unresolved adjusted regressions from being used for claim-bearing output
If you are deciding whether Licklider is suitable for your study, the important point is that adjusted linear regressions are not silently treated as ready-to-publish results. The product asks for an explicit disclosure step.
When this check activates
This check activates when all of the following are true:
- the figure is recognized as a linear regression
- the model includes two or more predictors
- a response column is available for the regression context
For example, a model such as Outcome ~ Age + BMI + Sex activates this check because the reported coefficient comes from a covariate-adjusted regression rather than a single-predictor fit.
A single-predictor regression does not trigger this check.
What Licklider asks you to confirm
When the check is active, Licklider asks you to resolve the covariate-adjustment disclosure before claim-bearing use.
The current resolution paths are:
Acknowledged and disclosed
Use this when the regression does include covariate adjustment and you will report that adjustment in the methods text, figure disclosure, or both.
Not applicable
Use this when the current analysis should not be treated as an adjusted claim in the way this disclosure is asking about.
If neither has been selected, the disclosure remains unresolved.
What happens if it stays unresolved
When covariate adjustment is detected but the disclosure is still unresolved, claim-bearing export is blocked.
Licklider also records a structured summary of the adjusted regression context so the unresolved state is tied to the actual model being reviewed, including:
- the response column
- the predictor columns used for adjustment
- the total predictor count
Once the disclosure is resolved, this specific export block is cleared and the resolved disclosure state is recorded with the figure.
What this check does and does not automate
This page has an important support boundary.
Licklider currently does automate the detection of multi-predictor linear regression in this disclosure path, and it does require the disclosure to be resolved before claim-bearing export can proceed.
Licklider currently does not use this check to determine:
- whether the covariates were pre-specified in a protocol
- whether the covariates were selected post-hoc after looking at the data
- whether stepwise regression or univariate screening was used
- whether the chosen covariates are scientifically sufficient to control confounding
- whether the same behavior is implemented across every regression family
That limitation matters because a disclosed adjusted model is not automatically a justified adjusted model. A result can honestly report that it adjusted for age, sex, and BMI and still rely on a weak, incomplete, or post-hoc covariate strategy. Licklider currently helps prevent hidden adjustment, but it does not yet perform a full automated review of covariate-selection validity.
Why the current check is narrower than the title
The title Covariate Selection Audit suggests a broader review of why predictors were included and whether the selection strategy was defensible.
The current implementation is narrower. It focuses on whether covariate adjustment is present in a multi-predictor linear regression and whether that adjustment has been disclosed before claim-bearing export.
This narrower scope is intentional in the current docs because it is better to describe the implemented behavior clearly than to imply a broader automated audit that the product does not yet perform.
Where to go next
- If your main question is whether the predictor set is structurally unstable or overfit, see Regression Diagnostics Guard.
- If your main question is whether the figure is overall ready for claim-bearing use, see Statistical Validity Score.
- If your main question is when to use linear regression in the first place, see Linear Regression (OLS).
What this page does not cover
- Full confounding-identification strategy
- Directed acyclic graphs, causal adjustment sets, or protocol design
- Stepwise model-building criticism as an implemented guard
- Logistic or Cox covariate-strategy support unless a dedicated page documents that implementation separately