Outcome Type and Analysis Intent

Two fields in the Data Contract shape how Licklider interprets your data and applies quality checks: the outcome type, which describes the nature of your response variable, and the analysis intent, which describes what kind of claim you are trying to make.

Outcome type

The outcome type tells Licklider what kind of values your response variable contains. This affects which statistical tests are appropriate and which quality checks are triggered.

Inferred values

Licklider infers the outcome type automatically when a dataset is loaded.

Inference follows this logic in order:

1. If a time-to-event column and an event indicator column are both detected — based on column name patterns and value structure — the outcome is classified as survival. This check runs before the others to prevent time columns and binary event columns from being misclassified as count or binary.
2. Values consistently bounded between 0 and 1, or identified as fractions or percentages, are classified as proportion.
3. Columns with exactly two unique values are classified as binary.
4. Columns of non-negative integers are classified as count.
5. All other numeric columns default to continuous.

What changes based on outcome type

Proportion and binary outcomes When a proportion or binary outcome is detected and a linear regression is requested, Licklider surfaces a warning. Linear regression applied to bounded outcomes can produce predictions outside the valid range and violates the assumptions of OLS. Logistic regression is the appropriate alternative.

Survival outcomes When a survival outcome is detected, Licklider requires a time-to-event column and an event indicator column. It enforces disclosures about censoring, at-risk counts, and median survival — all expected in publications using survival analysis.

Continuous and count outcomes No additional gate-level constraints are applied automatically beyond the standard normality and assumption checks that run for all group comparison analyses.

Reviewing and correcting the inferred outcome type

The inferred outcome type is visible in the Data Contract overview in the Inspector. If the inference is incorrect — for example, if a column of 0s and 1s represents a binary flag rather than an event indicator — tell Licklider in the Chat:

• "The outcome here is binary, not survival"
• "Treat this as a count outcome"

If the column structure is causing the misclassification, reformatting the column and re-uploading will trigger a fresh inference.

What you will see in practice

These fields do not directly produce a p-value or figure by themselves. Instead, they change what Licklider shows, requires, or warns about downstream. In practice, you should expect to see:

• The inferred outcome type in the Data Contract overview
• Warnings when the requested analysis is a poor match for the detected outcome structure
• Required disclosures for survival analyses, including censoring-related reporting expectations
• A visible analysis intent in the Data Contract once it is set
• Additional confirmation steps or blocking checks for confirmatory and publication-ready analyses when claim standards are stricter than in exploratory work

These outputs help you decide whether the current analysis setup matches the scientific question you actually want to answer.

Analysis intent

The analysis intent tells Licklider what kind of claim your analysis is designed to support. It does not change which statistical test runs, but it does affect which quality checks are applied and how strictly.

Available values

How to set the analysis intent

From the Inspector When analysis intent has not been set, a prompt appears in the Inspector Overview tab. Select the option that matches how you intend to use the result. Once set, the prompt disappears and the selected intent is shown in the Data Contract overview.

If you want to change the intent later, you can do so from the same panel.

From Chat If you have not set an intent and make an inferential request — for example, asking whether a difference is significant or whether a result is ready to publish — Licklider will ask you to choose an intent before proceeding. You can also state it directly:

• "This is an exploratory analysis"
• "I am preparing this for publication"

How analysis intent affects quality checks

Setting the intent to confirmatory or publication-ready activates stricter requirements in two areas:

Hypothesis direction and sidedness For confirmatory and publication-ready analyses, Licklider requires that the hypothesis direction (one-sided or two-sided) is explicitly documented. For exploratory analyses, this check runs but does not block the analysis.

Multiple comparisons For confirmatory and publication-ready analyses where multiple claims are made, Licklider enforces that a correction method is specified before results are shown. For exploratory analyses, the disclosure is surfaced automatically but the correction is not required.

Exploratory mode is more permissive and designed for iteration. Confirmatory and publication-ready modes are designed for analyses where the integrity of the claim matters and where you expect to be asked to justify your choices.

Analysis intent does not apply retroactively

Changing the intent affects the next analysis or figure generation. Existing figures that were generated under a different intent are not re-evaluated automatically. If you change intent mid-session, review previous results to confirm they meet the new standard.

What Licklider can and cannot determine automatically

Licklider can infer likely outcome structure from column names, value ranges, and column combinations, and it can use analysis intent to decide whether stricter quality gates should apply.

However, Licklider cannot determine scientific meaning when that meaning is not encoded clearly in the data or has not been declared by you. In particular, Licklider cannot reliably determine:

• Whether a 0/1 column is the true study endpoint, an event indicator for survival analysis, or only a workflow flag
• Whether bounded values represent a true proportion, a transformed continuous measurement, or a summary-derived percentage that should be modeled differently
• Whether a non-negative integer column is a true count outcome, an encoded category, or a rounded continuous measure
• Whether the intended claim is exploratory or confirmatory unless you explicitly set that intent
• Whether previously generated figures still satisfy a newly chosen intent without being reviewed again

These limits matter because the wrong outcome type can surface inappropriate warnings or analysis suggestions, and an unset or incorrect intent can make a claim look more settled than your study design actually supports.

That is why Licklider exposes the inferred type, allows correction through Chat or re-upload, and treats analysis intent as an explicit user decision rather than an automatic guess.

How these two fields interact

Outcome type and analysis intent are independent. Setting one does not affect the other. However, they can both influence the same quality check — for example, a survival outcome with confirmatory intent triggers both the survival-specific disclosures and the hypothesis direction requirement.

Design Rationale & References

This page follows a simple rule: structural interpretation and claim strength should be made explicit before inferential results are trusted. That is why Licklider infers an outcome type early, warns when the requested model is a poor fit for that type, and asks you to declare whether the work is exploratory, confirmatory, or publication-ready.

The ordering of the outcome inference is also deliberate. Survival is checked before simpler outcome classes because time-to-event data can otherwise be misread as ordinary time or binary columns. Bounded outcomes trigger warnings against ordinary linear modeling because models that ignore the outcome scale can produce invalid predictions and misleading interpretation [1]. Survival analyses carry specific reporting expectations around censoring and at-risk information, so Licklider surfaces those disclosures rather than treating survival as just another numeric endpoint [2].

The intent field exists because the same numerical result can support different strengths of claim depending on whether the analysis is exploratory or confirmatory. Requiring explicit multiplicity handling for stronger claims aligns with standard family-wise error control logic rather than leaving multiple testing implicit [3].

1. Warton, D. I., & Hui, F. K. C. (2011). The arcsine is asinine: the analysis of proportions in ecology. Ecology, 92(1), 3-10. https://doi.org/10.1890/10-0340.1
2. Morris, T. P., Jarvis, C. I., Cragg, W., et al. (2019). Proposals on Kaplan-Meier plots in medical research and a survey of stakeholder views: KMunicate. BMJ Open, 9, e030215. https://doi.org/10.1136/bmjopen-2019-030215
3. Holm, S. (1979). A simple sequentially rejective multiple test procedure. Scandinavian Journal of Statistics, 6(2), 65-70.

What this page does not cover

• Defining the hypothesis direction — see Hypothesis Direction and Sidedness
• How multiple comparisons are handled — see Multiplicity and Analysis Families
• How the variable mapping is inferred more broadly — see Variable and ID Mapping
• Survival-specific analysis setup — see Kaplan-Meier Analysis, Cox Proportional Hazards Regression