AVM™ + PCI™
Prediction Test / Baseline Protocol 0.1
Arquitectura de investigación común — Punto ⑤
Versión: 0.1
Estado: Protocolo metodológico inicial
Proyecto: AVM™ + PCI™
Función: Establecer una línea base experimental para evaluar la capacidad predictiva de la arquitectura AVM™ / PCI™.
1. Propósito del protocolo
El Prediction Test / Baseline Protocol 0.1 establece el procedimiento mediante el cual AVM™ + PCI™ puede pasar de la descripción y medición de fenómenos observados a la evaluación de su capacidad para anticipar resultados futuros o no observados.
Esta transición es metodológicamente importante.
Una metodología puede describir correctamente lo ocurrido y, sin embargo, no poseer capacidad predictiva.
Por tanto:
Describir un patrón no equivale a predecirlo.
El objetivo de este protocolo es crear una separación operacional entre:
lo que el sistema ha observado;
lo que la metodología propone como hipótesis;
lo que la metodología predice antes de observar el resultado;
lo que realmente sucede;
el grado de correspondencia entre predicción y resultado.
El protocolo no pretende demostrar todavía que AVM™ o PCI™ sean predictivos.
Su función inicial es mucho más básica y, precisamente por ello, más importante:
crear las condiciones bajo las cuales una capacidad predictiva pueda ser puesta a prueba y potencialmente falsada.
2. Posición dentro de la arquitectura de investigación común
El punto ⑤ se construye sobre los cuatro componentes anteriores:
① Research Architecture Review 0.1
Define y revisa la arquitectura general de investigación.
↓
② Evidence Map 0.1
Organiza qué evidencia existe, qué evidencia falta y qué relaciones pueden investigarse.
↓
③ AVM™ / PCI™ Knowledge & Evidence Boundary
Establece los límites entre conocimiento disponible, inferencia, hipótesis y afirmaciones no demostradas.
↓
④ PCI™ Longitudinal Research Architecture 0.1
Introduce la dimensión temporal y permite estudiar cómo evolucionan los fenómenos y sus relaciones.
↓
⑤ Prediction Test / Baseline Protocol 0.1
Introduce una prueba explícita de predicción previa al resultado.
La lógica completa puede representarse así:
Observación → Evidencia → Hipótesis → Modelo → Predicción → Observación posterior → Comparación → Evaluación
Esta secuencia constituye uno de los primeros mecanismos de control epistemológico del proyecto.
3. Problema metodológico que resuelve
En investigaciones sobre visibilidad en sistemas de IA existe un riesgo particularmente importante:
hindsight bias
Una vez conocido el resultado, es posible construir una explicación aparentemente coherente de por qué ocurrió.
Por ejemplo:
“La marca fue recomendada porque tenía una fuerte autoridad semántica.”
Pero si esa afirmación se formula después de observar la recomendación, no constituye una predicción.
Es una explicación post hoc.
El protocolo introduce por ello una regla fundamental:
Toda predicción utilizada para evaluar capacidad predictiva DEBE quedar registrada antes de que pueda conocerse el resultado que pretende anticipar.
Esto permite diferenciar:
Explicación retrospectiva
Resultado → explicación
de:
Predicción
Información disponible en T0 → predicción → resultado en T1
La segunda es la estructura que interesa evaluar.
4. Definición operacional de Prediction Test
Para AVM™ + PCI™, un Prediction Test es un experimento en el que:
existe un conjunto de información disponible en un momento inicial T0;
se formula una predicción explícita;
la predicción queda registrada y congelada;
se ejecuta posteriormente la medición o consulta correspondiente;
se registra el resultado observado;
se compara la predicción con el resultado;
se clasifica el grado de correspondencia;
se conserva también la evidencia de los fallos.
Formalmente:
I(T0) → P(T0) → O(T1) → C[P,O]
donde:
I(T0) = información disponible en el momento de predicción;
P(T0) = predicción registrada;
O(T1) = resultado observado posteriormente;
C[P,O] = comparación entre predicción y observación.
5. Qué significa «Baseline»
El término Baseline se utiliza deliberadamente.
Antes de intentar demostrar que AVM™ + PCI™ pueden realizar predicciones sofisticadas, es necesario establecer un punto de referencia.
La línea base debe responder a una pregunta sencilla:
¿Qué nivel de predicción puede obtenerse sin utilizar el modelo AVM™ / PCI™?
Por tanto, el protocolo debe permitir comparar al menos:
Baseline 0 — Sin modelo
Predicción basada en una regla simple, azar controlado, frecuencia histórica u otro mecanismo de referencia definido previamente.
Baseline 1 — Modelo AVM™
Predicción utilizando las variables y dimensiones desarrolladas por AVM™.
Baseline 2 — Modelo PCI™
Predicción utilizando las variables longitudinales y predictivas definidas por PCI™.
Baseline combinado
Predicción utilizando conjuntamente las variables autorizadas de AVM™ + PCI™.
No se presupone que ninguno de estos modelos será superior.
La comparación es precisamente el objeto del experimento.
6. Separación epistemológica obligatoria
El protocolo adopta tres categorías principales.
6.1 Evidencia real
Información efectivamente observada, registrada o medida.
Ejemplos:
respuestas reales de ChatGPT;
respuestas reales de Gemini;
respuestas reales de Claude;
respuestas reales de Perplexity;
fecha y hora de consulta;
prompt utilizado;
respuesta obtenida;
fuentes citadas;
posición de una marca;
frecuencia de aparición;
cambios observados longitudinalmente.
La evidencia real debe conservarse sin reinterpretación retrospectiva.
6.2 Hipótesis
Relación que se propone pero que todavía no ha sido demostrada.
Ejemplo:
H1: determinados patrones de reconocimiento, autoridad, atribución y consistencia podrían estar asociados con una mayor probabilidad de recomendación futura.
La utilización de “podrían” es deliberada.
Una hipótesis no debe convertirse lingüísticamente en un hecho antes de ser contrastada.
6.3 Material sintético
Cualquier dato, respuesta, escenario, dataset, predicción o resultado generado artificialmente para desarrollar o probar el diseño metodológico.
Debe etiquetarse expresamente como:
SINTÉTICO — NO EVIDENCIA EMPÍRICA
El material sintético puede utilizarse para:
probar el protocolo;
detectar errores;
diseñar estructuras;
simular escenarios;
validar procedimientos técnicos.
Pero nunca debe incorporarse posteriormente al corpus empírico como si fuese evidencia real.
7. Principio de congelación de la predicción
Este es uno de los principios centrales del protocolo.
Una predicción debe quedar frozen antes de observar el resultado.
El registro mínimo deberá contener:
| Campo | Función |
| Prediction ID | Identificación única |
| Fecha/hora T0 | Momento de predicción |
| Dataset disponible | Información utilizada |
| Variables utilizadas | Inputs autorizados |
| Hipótesis asociada | Relación que se pretende probar |
| Predicción | Resultado anticipado |
| Horizonte temporal | Momento o periodo esperado |
| Nivel de confianza | Incertidumbre declarada |
| Criterio de acierto | Regla previamente definida |
| Criterio de fallo | Regla previamente definida |
| Timestamp de congelación | Evidencia de pre-registro |
Una modificación posterior de la predicción debe generar una nueva versión, nunca sobrescribir la anterior.
8. Prediction Leakage
El protocolo deberá controlar explícitamente el prediction leakage.
Existe leakage cuando información disponible únicamente después de T0 termina influyendo en una predicción supuestamente realizada en T0.
Ejemplo:
Incorrecto
Se observa que una marca aumenta sus recomendaciones.
Se incorporan esos datos al modelo.
Se afirma que el modelo había predicho el aumento.
Eso no es predicción.
Es reconstrucción retrospectiva.
Regla:
Ningún dato posterior a T0 puede utilizarse para modificar una predicción ya registrada en T0.
9. Unidad experimental
La unidad experimental deberá definirse antes de cada Prediction Test.
Puede ser:
una marca;
una consulta;
un prompt;
un modelo de IA;
una categoría;
una respuesta;
una posición de recomendación;
una ventana temporal;
una combinación marca × modelo × prompt;
una combinación marca × contexto × periodo.
Por ejemplo:
Marca × Modelo × Prompt × Tiempo
puede constituir una unidad experimental.
La elección debe permanecer estable durante el experimento.
10. Qué puede predecirse
El protocolo no limita inicialmente la predicción a una única variable.
Sin embargo, las variables deben ser observables y operacionalizables.
Ejemplos potenciales:
Visibility Prediction
¿Será mencionada la marca?
Recognition Prediction
¿El sistema reconocerá la marca dentro de una categoría?
Recommendation Prediction
¿Será recomendada?
Priority Prediction
¿Aparecerá entre las primeras recomendaciones?
Attribution Prediction
¿El sistema atribuirá correctamente determinada característica a la marca?
Source Prediction
¿Qué fuentes podrían aparecer asociadas?
Consistency Prediction
¿La marca mantendrá aproximadamente el mismo patrón de visibilidad entre consultas/modelos?
Longitudinal Prediction
¿Aumentará, disminuirá o permanecerá estable determinada dimensión durante una ventana temporal?
Estas categorías son inicialmente targets potenciales, no resultados demostrados.
11. Predicción categórica y probabilística
El protocolo distingue dos niveles.
11.1 Predicción categórica
Ejemplo:
“La marca será recomendada.”
Resultado:
acertado;
fallido.
Es sencilla, pero limitada.
11.2 Predicción probabilística
Ejemplo:
“Probabilidad estimada de recomendación: 0,70.”
Posteriormente se observa si el evento ocurre.
Este segundo enfoque permite evaluar no solamente si el sistema acierta, sino también si sus niveles de confianza están bien calibrados.
Por ello, a largo plazo, PCI™ debería evolucionar hacia:
predicción + probabilidad + calibración.
12. Horizonte temporal
Toda predicción deberá especificar su horizonte.
Ejemplos:
T+1 consulta;
T+7 días;
T+30 días;
T+90 días;
T+6 meses;
T+12 meses.
Esto es especialmente relevante para PCI™, porque una predicción sin horizonte temporal es metodológicamente ambigua.
No es equivalente afirmar:
“La visibilidad aumentará.”
que:
“La probabilidad de recomendación aumentará durante los próximos 90 días.”
La segunda puede ser contrastada.
13. Baseline mínimo obligatorio
Antes de introducir variables complejas deberá existir una referencia mínima.
Un baseline puede ser:
Baseline histórico
Predice el futuro utilizando el comportamiento histórico.
Ejemplo:
si una marca fue recomendada el 70 % de las veces en la ventana anterior, el baseline predice una probabilidad del 70 %.
Baseline de frecuencia
Utiliza únicamente la frecuencia observada.
Baseline aleatorio
Sirve como referencia experimental cuando sea apropiado.
Baseline heurístico
Utiliza una regla simple previamente definida.
La elección dependerá del experimento.
El objetivo no es encontrar el baseline “más favorable”, sino uno reproducible y justificable.
14. Comparación entre baseline y modelo
La pregunta central no será:
“¿Acertó AVM™ + PCI™?”
sino:
“¿Predice mejor que una referencia razonable?”
Esta diferencia es fundamental.
Un modelo con 65 % de aciertos puede parecer bueno.
Pero si el baseline obtiene 70 %, el modelo no aporta evidencia de superioridad predictiva.
Por tanto:
Valor predictivo = rendimiento del modelo − rendimiento del baseline
No necesariamente como simple resta numérica —la métrica dependerá del target—, pero sí como principio comparativo.
15. Métricas iniciales
La selección definitiva deberá depender del tipo de predicción.
Para targets binarios pueden utilizarse:
Accuracy;
Precision;
Recall;
F1;
ROC-AUC, cuando sea apropiado;
Log Loss;
Brier Score.
Para predicciones probabilísticas resulta especialmente relevante:
Brier Score
Permite evaluar la calidad de las probabilidades predichas.
Y para estudios longitudinales:
error absoluto;
error relativo;
desviación temporal;
estabilidad de la predicción;
calibración por periodo.
No se debe elegir la métrica después de observar qué métrica favorece al modelo.
16. Criterios de éxito
Antes de ejecutar el experimento deben definirse:
Primary endpoint
La variable principal que determinará el resultado del experimento.
Secondary endpoints
Variables adicionales.
Success criterion
Qué resultado constituirá evidencia favorable.
Failure criterion
Qué resultado constituirá evidencia desfavorable.
Null result
Qué resultado se considerará inconcluso o compatible con ausencia de capacidad predictiva demostrable.
Esta distinción es importante porque:
“No demostrar capacidad predictiva” no equivale automáticamente a “demostrar que no existe capacidad predictiva”.
17. Registro de predicciones
Cada predicción deberá recibir un identificador único.
Ejemplo:
PCI-PT-001
Podría estructurarse como:
Proyecto – Test – Predicción
Ejemplo:
PCI-PT-001-P01
o:
AVM-PCI-PT01-P001
El identificador debe permitir reconstruir posteriormente:
cuándo se realizó;
qué información estaba disponible;
qué modelo intervino;
qué predicción produjo;
qué resultado ocurrió;
cómo fue evaluada.
18. Prediction Ledger
Se propone establecer un registro longitudinal:
| Prediction ID | T0 | Target | Predicción | Probabilidad | T1 | Resultado | Score | Estado |
| PT-001 | fecha | Recommendation | Sí | 0,70 | fecha | Sí | — | Hit |
| PT-002 | fecha | Priority | No | 0,30 | fecha | Sí | — | Miss |
| PT-003 | fecha | Attribution | Sí | 0,80 | fecha | Sí | — | Hit |
Este registro constituye el equivalente experimental de un Prediction Ledger.
No debe eliminarse una predicción fallida.
Los fallos forman parte de la evidencia.
19. Regla de no selección retrospectiva
No se permitirá seleccionar únicamente las predicciones acertadas.
El dataset deberá conservar:
Hits + Misses + Uncertain/Invalid
La exclusión de una predicción solo podrá realizarse mediante una regla definida previamente.
Por ejemplo:
una predicción será considerada inválida si el target no pudo medirse por una interrupción documentada del experimento.
Pero:
una predicción no puede considerarse inválida simplemente porque resultó incorrecta.
20. Control de cambios
El protocolo debe conservar versiones.
Ejemplo:
Prediction Protocol 0.1
↓
Prediction Protocol 0.2
↓
Prediction Protocol 1.0
Una modificación de:
target;
métrica;
horizonte;
baseline;
criterio de éxito;
variables;
método de evaluación;
debe quedar registrada.
Nunca deberá utilizarse una modificación metodológica posterior para reinterpretar retrospectivamente resultados anteriores sin etiquetarla como tal.
21. Primer diseño experimental recomendado
El primer Prediction Test de AVM™ + PCI™ debería mantenerse deliberadamente pequeño.
Fase A — Dataset histórico
Utilizar exclusivamente observaciones reales ya registradas.
Fase B — Corte temporal
Separar:
Training / Historical Window
de:
Prediction / Future Window
Fase C — Predicción congelada
Construir la predicción utilizando únicamente información anterior al corte.
Fase D — Observación
Ejecutar las consultas reales posteriores.
Fase E — Evaluación
Comparar:
Baseline vs AVM™ vs PCI™ vs AVM™ + PCI™
Fase F — Auditoría
Registrar:
aciertos;
fallos;
predicciones ambiguas;
datos faltantes;
modificaciones;
desviaciones del protocolo.
22. Ejemplo conceptual
Supongamos que durante un periodo histórico se han registrado 20 consultas sobre una marca.
Se observa:
reconocimiento frecuente;
identificación consistente;
atribución parcial;
recomendación ocasional;
variación entre modelos.
A partir de T0 se formula:
Hipótesis: determinados niveles combinados de reconocimiento, autoridad, atribución y consistencia podrían aumentar la probabilidad de recomendación posterior.
Se registra:
Predicción: probabilidad de recomendación en la siguiente ventana = 0,70.
La predicción queda congelada.
Posteriormente se realizan las consultas correspondientes.
El resultado real puede ser:
Sí → predicción acertada
o:
No → predicción fallida
Lo importante no es que el primer test acierte.
Lo importante es que el procedimiento permita saberlo sin modificar la historia después del resultado.
23. Relación entre AVM™ y PCI™
El protocolo permite asignar funciones diferenciadas.
AVM™
AVM™ se ocupa principalmente de medir y estructurar el estado observable de la visibilidad.
Puede proporcionar variables como:
recognition;
identification;
attribution;
recommendation;
priority;
consistency;
context;
sources.
PCI™
PCI™ añade una dimensión longitudinal y de investigación predictiva.
Su función potencial es estudiar:
cómo los estados observados en T0 se relacionan con estados posteriores en T1, T2, T3…
La relación puede expresarse inicialmente como:
AVM State(T0) → PCI Observation/Prediction → AVM State(T1)
Esto no significa que exista todavía una relación causal demostrada.
Es una arquitectura experimental para comprobar si existe capacidad predictiva.
24. Causalidad ≠ predicción
Este punto debe quedar explícitamente protegido.
Si una variable permite predecir otra, eso no demuestra que la primera cause la segunda.
Por ejemplo:
“Mayor consistencia precede a mayor recomendación.”
podría convertirse en una relación predictiva observada.
Pero no permite afirmar automáticamente:
“La consistencia causa la recomendación.”
El protocolo debe mantener separadas:
correlación → predicción → causalidad
Son niveles diferentes de afirmación.
25. Prediction Test como mecanismo de falsación
La utilidad científica del protocolo no depende de confirmar AVM™ + PCI™.
También debe poder demostrar que determinadas hipótesis no funcionan.
Por ello:
Un buen Prediction Test debe estar diseñado para poder fallar.
Si una metodología siempre puede reinterpretar cualquier resultado como compatible con su teoría, no existe una verdadera prueba predictiva.
El protocolo debe favorecer, por tanto:
predicciones específicas;
targets observables;
horizontes temporales definidos;
criterios previos;
registro inmutable;
evaluación independiente del resultado.
26. Data Split temporal
PCI™ deberá favorecer, cuando el volumen de datos lo permita, una separación temporal:
Past → Training
Cut-off → Freeze
Future → Test
Nunca:
Past + Future → Prediction
cuando el objetivo sea medir predicción fuera de muestra.
La separación temporal es especialmente importante porque las respuestas de los sistemas de IA pueden cambiar debido a:
actualización del modelo;
cambios de fuentes;
cambios de ranking;
modificaciones del comportamiento del sistema;
cambios en la información disponible;
cambios en el propio prompt o contexto.
27. Reproducibilidad
Todo Prediction Test debería permitir que un tercero pueda reconstruir:
qué datos se utilizaron;
qué información estaba disponible en T0;
qué predicción se realizó;
cuándo se realizó;
qué versión del protocolo se utilizó;
qué modelo produjo la predicción;
qué resultado se obtuvo;
qué criterio determinó el éxito o fracaso;
qué cambios se produjeron durante el experimento.
La reproducibilidad no significa necesariamente obtener exactamente la misma respuesta de un sistema de IA.
Significa poder reproducir el procedimiento experimental y sus condiciones documentadas.
28. Variabilidad de los modelos de IA
En AVM™ + PCI™ existe una dificultad adicional:
los sistemas de IA pueden ser no deterministas.
Por ello, una predicción no debe evaluarse sin registrar:
modelo;
versión disponible, cuando sea identificable;
fecha;
prompt;
configuración relevante conocida;
contexto proporcionado;
respuesta completa;
fuentes;
condiciones de consulta.
Cuando una versión exacta no pueda determinarse, deberá registrarse como desconocida/no disponible, nunca inferirse.
29. Repetición y estabilidad
Una sola predicción no constituye evidencia suficiente de una capacidad predictiva general.
Será necesario estudiar:
Repetibilidad
¿El procedimiento produce resultados similares al repetirse?
Robustez
¿La predicción mantiene su rendimiento ante variaciones razonables?
Generalización
¿Funciona fuera del conjunto utilizado para construirla?
Cross-model validity
¿Funciona en diferentes sistemas?
Temporal validity
¿Mantiene rendimiento en distintos periodos?
Estas dimensiones deberán desarrollarse en versiones posteriores del protocolo.
30. Niveles de madurez predictiva
Se propone inicialmente una escala conceptual:
Nivel P0 — Sin predicción
Solo descripción retrospectiva.
Nivel P1 — Predicción informal
Existe una expectativa, pero no está congelada ni operacionalizada.
Nivel P2 — Predicción registrada
La predicción queda registrada antes del resultado.
Nivel P3 — Predicción evaluada
Existe comparación formal con el resultado.
Nivel P4 — Predicción comparada
El modelo supera o iguala de forma documentada un baseline definido.
Nivel P5 — Predicción calibrada
Las probabilidades predichas muestran calibración adecuada.
Nivel P6 — Predicción reproducible
El rendimiento se mantiene en diferentes muestras, periodos o modelos.
Esta escala es provisional y deberá considerarse hipótesis metodológica, no estándar validado.
31. Qué NO debe afirmarse todavía
Hasta disponer de experimentación suficiente, el proyecto no debería afirmar:
que AVM™ predice la visibilidad;
que PCI™ predice cambios de visibilidad;
que una determinada variable causa otra;
que una combinación de variables garantiza recomendaciones;
que una puntuación AVM™ determina el comportamiento futuro de un sistema de IA;
que un modelo predictivo general ha sido validado.
La formulación correcta será:
“El protocolo permite evaluar si determinadas variables observadas presentan capacidad predictiva respecto a determinados resultados posteriores.”
32. Evidencia mínima para una primera afirmación predictiva
Una futura afirmación de capacidad predictiva debería apoyarse, como mínimo, en:
predicciones realizadas antes de los resultados;
dataset suficientemente documentado;
separación temporal;
baseline explícito;
criterios de evaluación predefinidos;
registro de aciertos y fallos;
ausencia de leakage;
repetición;
análisis de incertidumbre;
documentación de limitaciones.
La cantidad exacta de observaciones necesaria no debe fijarse arbitrariamente en este documento; deberá determinarse según el target, diseño y análisis estadístico del experimento correspondiente.
33. Registro epistemológico
Cada Prediction Test deberá mantener cuatro capas separadas:
| Capa | Contenido | Estado |
| E1 | Evidencia observada | REAL |
| E2 | Interpretación | ANALÍTICA |
| E3 | Hipótesis | NO DEMOSTRADA |
| E4 | Predicción | PRE-REGISTRADA |
Después del test se añade:
| Capa | Contenido |
| E5 | Resultado observado |
| E6 | Evaluación de la predicción |
| E7 | Actualización de la hipótesis |
Esto crea un ciclo:
Evidencia → Hipótesis → Predicción → Resultado → Evaluación → Nueva evidencia
34. Arquitectura temporal
El protocolo introduce explícitamente:
T−n
Histórico disponible.
T0
Punto de corte.
T0+
Predicción congelada.
T1
Primera observación futura.
T2
Segunda observación.
T3…
Observaciones posteriores.
La arquitectura permite estudiar si las relaciones observadas en T0 poseen valor predictivo en diferentes horizontes.
35. Resultado esperado del punto ⑤
El producto principal de este documento no es todavía un modelo predictivo.
Es un marco experimental que impide confundir explicación retrospectiva con predicción real.
Por tanto, el entregable de esta fase debe ser:
Prediction Test Protocol 0.1
junto con:
Prediction Ledger 0.1
Baseline Definition 0.1
Prediction Evaluation Schema 0.1
Estos componentes permitirán que futuros experimentos sean comparables entre sí.
36. Principio rector
El principio fundamental de este punto puede resumirse así:
No se considerará evidencia de capacidad predictiva ninguna predicción reconstruida después de conocer el resultado.
Y una segunda regla complementaria:
Una predicción acertada de forma aislada no demuestra capacidad predictiva general.
La evidencia de capacidad predictiva deberá surgir de un conjunto de predicciones pre-registradas, evaluadas contra resultados futuros y comparadas con un baseline razonable.
37. Relación con los puntos posteriores
El punto ⑤ deja preparada la arquitectura para las siguientes capas de investigación:
⑤ Prediction Test / Baseline Protocol
↓
Prediction Dataset
↓
Prediction Calibration
↓
Cross-Model Prediction Test
↓
Longitudinal Validation
↓
Out-of-Sample Validation
↓
Predictive Model Evaluation
Pero estas fases no deben considerarse todavía desarrolladas ni validadas.
Son únicamente una proyección metodológica de continuidad.
38. Estado epistemológico del documento
| Elemento | Estado |
| Necesidad de separar predicción de explicación retrospectiva | Principio metodológico |
| Prediction Freeze | Propuesta metodológica |
| Prediction Ledger | Propuesta metodológica |
| Baseline obligatorio | Propuesta metodológica |
| Temporal Split | Propuesta metodológica |
| Comparación AVM™ / PCI™ / Baseline | Diseño experimental |
| Niveles P0–P6 | Taxonomía provisional |
| Capacidad predictiva de AVM™ | NO DEMOSTRADA |
| Capacidad predictiva de PCI™ | NO DEMOSTRADA |
| Relación causal entre variables | NO DEMOSTRADA |
| Superioridad de AVM™ + PCI™ frente a baseline | NO DEMOSTRADA |
Conclusión
El Prediction Test / Baseline Protocol 0.1 representa un cambio de fase dentro de la arquitectura AVM™ + PCI™.
Hasta este punto, la investigación puede estudiar:
qué ocurre, cómo medirlo, cómo clasificarlo y cómo evoluciona.
Con este protocolo aparece una pregunta adicional:
¿Podemos anticipar, utilizando únicamente información disponible antes del resultado, qué ocurrirá después?
La importancia de esta pregunta no reside en conseguir rápidamente un modelo que “acierte”.
Reside en establecer un mecanismo que permita distinguir entre:
descripción, interpretación, hipótesis, predicción, resultado y validación.
Ese mecanismo convierte la predicción en un objeto experimental auditable.
Y establece una condición esencial para el desarrollo posterior de PCI™:
PCI™ no deberá considerarse predictivo porque explique bien el pasado. Deberá demostrar que puede anticipar resultados futuros bajo condiciones previamente definidas, superar un baseline razonable y mantener ese rendimiento fuera de la muestra utilizada para construir la predicción.
Por tanto, el punto ⑤ no demuestra todavía capacidad predictiva.
Construye las reglas mediante las cuales esa capacidad podrá, por primera vez, ser puesta a prueba.
Estado del documento
AVM™ + PCI™ Prediction Test / Baseline Protocol 0.1
Función: protocolo de transición de observación longitudinal a evaluación predictiva.
Evidencia empírica incorporada: únicamente la previamente registrada en el corpus AVM™ / PCI™ cuando sea utilizada como dataset histórico.
Material sintético: no constituye evidencia y deberá etiquetarse separadamente.
Hipótesis: permanecen abiertas hasta su contrastación.
Capacidad predictiva de AVM™ / PCI™: no demostrada en esta versión.
Resultado: marco metodológico preparado para la ejecución de los primeros Prediction Tests reales.
