Agent-almanac validate-statistical-output
git clone https://github.com/pjt222/agent-almanac
T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/es/skills/validate-statistical-output" ~/.claude/skills/pjt222-agent-almanac-validate-statistical-output-d339a1 && rm -rf "$T"
i18n/es/skills/validate-statistical-output/SKILL.mdValidar Salida Estadística
Verificar los resultados de análisis estadísticos mediante cálculo independiente y comparación sistemática.
Cuándo Usar
- Al validar análisis de endpoints primarios y secundarios para envíos regulatorios
- Al realizar programación doble (R vs SAS, o implementaciones R independientes)
- Al verificar que el código de análisis produce resultados correctos
- Al revalidar tras cambios en el código o el entorno
Entradas
- Requerido: Código de análisis primario y resultados
- Requerido: Resultados de referencia (cálculo independiente, valores publicados o datos de prueba conocidos)
- Requerido: Criterios de tolerancia para comparaciones numéricas
- Opcional: Contexto del envío regulatorio
Procedimiento
Paso 1: Definir el Marco de Comparación
# Define tolerance levels for different statistics tolerances <- list( counts = 0, # Exact match for integers proportions = 1e-4, # 0.01% for proportions means = 1e-6, # Numeric precision for means p_values = 1e-4, # 4 decimal places for p-values confidence_limits = 1e-3 # 3 decimal places for CIs )
Esperado: Niveles de tolerancia definidos para cada categoría de estadístico, con tolerancias más estrictas para conteos enteros (coincidencia exacta) y tolerancias más amplias para estadísticos de punto flotante (valores p, intervalos de confianza).
En caso de fallo: Si los niveles de tolerancia están en disputa, documentar el fundamento de cada umbral y obtener la aprobación del responsable estadístico antes de proceder. Consultar las guías ICH E9 para envíos regulatorios.
Paso 2: Crear la Función de Comparación
#' Compare two result sets with tolerance-based matching #' #' @param primary Results from the primary analysis #' @param reference Results from the independent calculation #' @param tolerances Named list of tolerance values #' @return Data frame with comparison results compare_results <- function(primary, reference, tolerances) { stopifnot(names(primary) == names(reference)) comparison <- data.frame( statistic = names(primary), primary_value = unlist(primary), reference_value = unlist(reference), stringsAsFactors = FALSE ) comparison$absolute_diff <- abs(comparison$primary_value - comparison$reference_value) comparison$tolerance <- sapply(comparison$statistic, function(s) { # Match to tolerance category or use default tol <- tolerances[[s]] if (is.null(tol)) tolerances$means # default tolerance else tol }) comparison$pass <- comparison$absolute_diff <= comparison$tolerance comparison }
Esperado:
compare_results() devuelve un data frame con columnas para el nombre del estadístico, valor primario, valor de referencia, diferencia absoluta, tolerancia y estado aprobado/fallido.
En caso de fallo: Si la función genera error por nombres no coincidentes, verificar que ambas listas de resultados usan nombres de estadísticos idénticos. Si el mapeo de tolerancias falla, añadir una tolerancia predeterminada para nombres de estadísticos no reconocidos.
Paso 3: Implementar la Programación Doble
Escribir una implementación independiente que llegue a los mismos resultados mediante código diferente:
# PRIMARY ANALYSIS (in R/primary_analysis.R) primary_analysis <- function(data) { model <- lm(endpoint ~ treatment + baseline + sex, data = data) coefs <- summary(model)$coefficients list( treatment_estimate = coefs["treatmentActive", "Estimate"], treatment_se = coefs["treatmentActive", "Std. Error"], treatment_p = coefs["treatmentActive", "Pr(>|t|)"], n_subjects = nobs(model), r_squared = summary(model)$r.squared ) } # INDEPENDENT VERIFICATION (in validation/independent_analysis.R) # Written by a different analyst or using different methodology independent_analysis <- function(data) { # Using matrix algebra instead of lm() X <- model.matrix(~ treatment + baseline + sex, data = data) y <- data$endpoint beta <- solve(t(X) %*% X) %*% t(X) %*% y residuals <- y - X %*% beta sigma2 <- sum(residuals^2) / (nrow(X) - ncol(X)) var_beta <- sigma2 * solve(t(X) %*% X) se <- sqrt(diag(var_beta)) t_stat <- beta["treatmentActive"] / se["treatmentActive"] p_value <- 2 * pt(-abs(t_stat), df = nrow(X) - ncol(X)) list( treatment_estimate = as.numeric(beta["treatmentActive"]), treatment_se = se["treatmentActive"], treatment_p = as.numeric(p_value), n_subjects = nrow(data), r_squared = 1 - sum(residuals^2) / sum((y - mean(y))^2) ) }
Esperado: Existen dos implementaciones independientes que usan rutas de código diferentes (por ejemplo,
lm() vs álgebra matricial) para llegar a los mismos resultados estadísticos. Las implementaciones son escritas por analistas diferentes o usan métodos fundamentalmente distintos.
En caso de fallo: Si la implementación independiente produce resultados diferentes, primero verificar que ambas usan los mismos datos de entrada (comparar
digest::digest(data)). Luego verificar si hay diferencias en el manejo de NA, codificación de contrastes o cálculos de grados de libertad.
Paso 4: Ejecutar la Comparación
# Execute both analyses primary_results <- primary_analysis(study_data) independent_results <- independent_analysis(study_data) # Compare comparison <- compare_results(primary_results, independent_results, tolerances) # Report cat("Validation Comparison Report\n") cat("============================\n") cat(sprintf("Date: %s\n", Sys.time())) cat(sprintf("Overall: %s\n\n", ifelse(all(comparison$pass), "ALL PASS", "DISCREPANCIES FOUND"))) print(comparison)
Esperado: El informe de comparación muestra todos los estadísticos dentro de la tolerancia. La línea
Overall dice "ALL PASS".
En caso de fallo: Si se encuentran discrepancias, no asumir inmediatamente que el análisis primario es incorrecto. Investigar ambas implementaciones: verificar los cálculos intermedios, confirmar datos de entrada idénticos y comparar el manejo de valores faltantes y casos extremos.
Paso 5: Comparar contra Referencia Externa (SAS)
Al comparar la salida de R contra SAS:
# Load SAS results (exported as CSV or from .sas7bdat) sas_results <- list( treatment_estimate = 1.2345, # From SAS PROC GLM output treatment_se = 0.3456, treatment_p = 0.0004, n_subjects = 200, r_squared = 0.4567 ) comparison <- compare_results(primary_results, sas_results, tolerances) # Known sources of difference between R and SAS: # - Default contrasts (R: treatment, SAS: GLM parameterization) # - Rounding of intermediate calculations # - Handling of missing values (na.rm vs listwise deletion)
Esperado: Los resultados de comparación R-vs-SAS están dentro de la tolerancia, con cualquier diferencia sistemática conocida (codificación de contrastes, redondeo) documentada y explicada.
En caso de fallo: Si R y SAS producen resultados diferentes más allá de la tolerancia, verificar las tres fuentes más comunes de divergencia: codificación de contrastes predeterminada (R usa contrastes de tratamiento, SAS usa parametrización GLM), manejo de valores faltantes y redondeo de cálculos intermedios. Documentar cada diferencia con su causa raíz.
Paso 6: Documentar los Resultados
Crear un informe de validación:
# validation/output_comparison_report.R sink("validation/output_comparison_report.txt") cat("OUTPUT VALIDATION REPORT\n") cat("========================\n") cat(sprintf("Project: %s\n", project_name)) cat(sprintf("Date: %s\n", format(Sys.time()))) cat(sprintf("Primary Analyst: %s\n", primary_analyst)) cat(sprintf("Independent Analyst: %s\n", independent_analyst)) cat(sprintf("R Version: %s\n\n", R.version.string)) cat("COMPARISON RESULTS\n") cat("------------------\n") print(comparison, row.names = FALSE) cat(sprintf("\nOVERALL VERDICT: %s\n", ifelse(all(comparison$pass), "VALIDATED", "DISCREPANCIES - INVESTIGATION REQUIRED"))) cat("\nSESSION INFO\n") print(sessionInfo()) sink()
Esperado: Un archivo de informe de validación completo existe en
validation/output_comparison_report.txt que contiene metadatos del proyecto, resultados de comparación, veredicto general e información de la sesión.
En caso de fallo: Si
sink() falla o produce un archivo vacío, verificar que el directorio de salida existe (dir.create("validation", showWarnings = FALSE)) y que ninguna llamada previa a sink() sigue activa (usar sink.number() para verificar).
Paso 7: Gestionar las Discrepancias
Cuando los resultados no coinciden:
- Verificar que ambas implementaciones usan los mismos datos de entrada (comparación de hashes)
- Verificar si hay diferencias en el manejo de NA
- Comparar los cálculos intermedios paso a paso
- Documentar la causa raíz
- Determinar si la diferencia es aceptable (dentro de la tolerancia) o requiere corrección del código
Esperado: Todas las discrepancias son investigadas, las causas raíz identificadas y cada una clasificada como aceptable (dentro de la tolerancia con razón documentada) o que requiere corrección del código.
En caso de fallo: Si una discrepancia no puede explicarse, escalar al responsable estadístico. No ignorar las diferencias inexplicables, ya que pueden indicar un error genuino en una de las implementaciones.
Validación
- El análisis independiente produce resultados dentro de la tolerancia
- Todos los estadísticos de comparación están documentados
- Las discrepancias (si las hay) están investigadas y resueltas
- La integridad de los datos de entrada está verificada (coincidencia de hashes)
- Los criterios de tolerancia están preespecificados y justificados
- El informe de validación está completo y firmado
Errores Comunes
- El mismo analista escribe ambas implementaciones: La programación doble requiere analistas independientes para una verdadera validación
- Compartir código entre implementaciones: La versión independiente no debe copiar del análisis primario
- Tolerancia inapropiada: Demasiado laxa oculta errores reales; demasiado estricta marca ruido de punto flotante
- Ignorar las diferencias sistemáticas: Pequeños sesgos consistentes pueden indicar un error real incluso dentro de la tolerancia
- No validar la validación: Verificar que el código de comparación en sí funciona correctamente con entradas conocidas
Habilidades Relacionadas
— estructura del proyecto para trabajo validadosetup-gxp-r-project
— plantillas de protocolos e informeswrite-validation-documentation
— seguimiento del proceso de validación en síimplement-audit-trail
— conjuntos de pruebas automatizadas para validación continuawrite-testthat-tests