Survival Data Detection Guard

How Licklider detects survival data structure, what it checks before survival results can be claimed, and what disclosures are required.

Survival data - also called time-to-event data - has a structure that requires specific analysis methods and specific reporting conventions. A standard group comparison applied to survival data ignores censoring, which biases the results and misrepresents the evidence.

Licklider detects survival data structure automatically and confirms that the analysis and visualization are appropriate before allowing claim-bearing output.

This page does not produce a separate statistical result of its own. Instead, it explains how Licklider decides whether a reported result should be treated as survival analysis and whether the required safeguards for claim-bearing use are in place.

Detection and inference

Licklider infers survival structure from the dataset when it finds a combination of:

  • A column whose name suggests a time-to-event variable (for example: survival, time_to, days_to, os, pfs, tte)
  • A column whose name or values suggest an event indicator (for example: event, status, death, censored, relapse)
  • Values in the time column that are non-negative and numeric

When these conditions are met, the outcome type is set to survival in the Data Contract. This inference runs before the analysis begins.

This detection is intentionally heuristic. It is meant to catch common survival-data patterns early, before a non-survival analysis is treated as if it were appropriate for time-to-event data.

Licklider cannot determine automatically whether a nonstandard column name, an unusual event coding scheme, a time origin chosen outside the dataset, or censoring information stored only in notes or metadata should change the interpretation. If the table does not clearly expose a time-to-event column and an event indicator, the guard may miss a true survival outcome or may flag a dataset that only resembles one.

These limits matter because a missed survival structure can allow an inappropriate mean-based comparison to proceed, while a false survival interpretation can push the analysis into the wrong reporting path. In either case, the result can look cleaner and more certain than the study design actually supports.

What the guard checks

After survival structure is detected, Licklider confirms that the analysis and display are handled appropriately. Specifically, it checks for the following issues:

Non-survival visualization

Whether a survival-appropriate visualization (such as a Kaplan-Meier curve) was used, or whether the data was visualized using a method that does not account for censoring (such as a bar chart of mean survival times).

Non-survival comparison

Whether a survival-appropriate test (such as the log-rank test) was used, or whether a standard group comparison was applied without accounting for the time-to-event structure.

Censoring disclosure missing

Whether the proportion of censored observations was disclosed. Censoring affects the reliability of survival estimates and must be reported.

At-risk table missing

Whether the number of subjects remaining at risk at each time point was disclosed. This is expected in publications presenting Kaplan-Meier curves.

Median survival not estimable

When fewer than half of subjects have experienced the event, the median survival time cannot be estimated from the data. Claiming a specific median in this situation is not supported.

These checks focus on the most common ways survival results are misreported: using a display that ignores censoring, using a comparison that ignores time to event, omitting censoring disclosure, omitting the number at risk, or claiming a median that the data do not support.

What you are asked to confirm

When any of the above issues is detected, Licklider presents three options:

Survival method acknowledged

The analysis uses survival-appropriate methods, censoring is disclosed, and at-risk information is included. The result is eligible for claim-bearing export with the required disclosures.

Not a survival outcome

The data is not actually survival data - for example, the time column represents a continuous measurement rather than time to an event. Select this to remove the survival interpretation.

Descriptive only

The survival requirements cannot be met at this time. The result is treated as descriptive and is not eligible for claim-bearing export.

The confirmation step exists because pattern-based detection is helpful but not self-explanatory. A column named status may be an event indicator, or it may mean something else entirely. The software can surface the survival-like structure, but the scientific interpretation still depends on the study design and the declared endpoint.

Effect on export

When survival structure is confirmed and all required disclosures are present, claim-bearing export is allowed. When any issue is unresolved, for example when censoring has not been disclosed, claim-bearing export is blocked.

At lower confidence levels, when the survival structure is detected but not clearly confirmed, the guard surfaces a warning rather than blocking export.

This design is deliberate. Survival safeguards are connected to claim-bearing export because censoring, time-to-event structure, and the number at risk all change how strongly a reader should trust the visual pattern or p-value. Requiring disclosure makes that structure visible at the point where a result would otherwise be exported as a formal claim.

Lower-confidence cases are treated as warnings rather than automatic blocks because the same column names and value patterns can arise from non-survival data. A blanket hard block on weak heuristics would create avoidable friction for datasets whose variables only happen to resemble time-to-event structure.

Design Rationale & References

This page follows a simple rule: if the data behaves like time-to-event data, the analysis and reporting path should respect censoring and follow-up support before the result is treated as claim-bearing.

That is why Licklider looks for a time variable, an event indicator, and plausible non-negative time values before setting the outcome type to survival. It is also why the guard checks for survival-aware visualization, survival-aware comparison, censoring disclosure, at-risk reporting, and whether median survival is actually estimable from the observed follow-up.

At-risk information is required because the tail of a survival curve may be supported by very few remaining subjects. Censoring disclosure is required because the curve cannot be interpreted responsibly without knowing how much of the follow-up is censored. Median survival is blocked when not estimable because a specific median claim would imply more information than the data contain.

  1. Kaplan, E. L., & Meier, P. (1958). Nonparametric Estimation from Incomplete Observations. Journal of the American Statistical Association, 53(282), 457-481.
  2. Pocock, S. J., Clayton, T. C., & Altman, D. G. (2002). Survival plots of time-to-event outcomes in clinical trials: good practice and pitfalls. The Lancet, 359(9318), 1686-1689. https://doi.org/10.1016/S0140-6736(02)08594-8

These references support the use of censoring-aware survival methods and the reporting importance of survival-plot disclosures. In Licklider, the guard uses those principles to decide when a result is ready for claim-bearing export; it does not guarantee that every survival-design issue has been detected automatically.

What this page does not cover