La importancia de un observable es que puede llevar mucha información, incluso si depende de variables ocultas. Por ejemplo, el orden de ejecución de las transacciones es un observable. Depende claramente de variables ocultas, como el flujo de órdenes. Sin embargo, aún es posible construir un estimador a partir del observable y probar supuestos o modelos para evaluar la reproducibilidad del evento observado, sin necesariamente conocer la variable oculta. Podemos comparar el orden de ejecución real con uno ideal, donde las transacciones están perfectamente ordenadas por prioridad, definiendo una distancia entre el orden real y el orden ideal. A partir de esto, obtenemos una distribución específica para cada programador. Bajo supuestos básicos, como el tiempo dedicado a programar transacciones antes de la ejecución y el grado de paralelización, podemos reproducir las distribuciones medidas utilizando simulaciones donde se asume que el flujo de órdenes es uniforme entre todos los programadores. Encontramos que: - un programador que ejecuta transacciones a medida que se vuelven disponibles, utilizando la prioridad solo para resolver transacciones concurrentes, reproduce casi perfectamente Agave - un programador que agrupa y ejecuta transacciones cada 50 ms reproduce casi perfectamente BAM - un programador que espera hasta cerca del final del slot antes de ejecutar todo reproduce casi perfectamente el programador de ingresos de Frankendancer Nada de esto asume disparidades en el flujo de órdenes. ¿Significa esto que el flujo de órdenes puede ser eliminado como una variable oculta? No. El hecho de que un modelo reproduzca los datos no implica que las perturbaciones al modelo no puedan tener efectos en cola, haciendo del flujo de órdenes una variable esencial al estudiar valores atípicos o eventos anómalos repetidos. ¿Significa esto que no se puede aprender nada operando bajo un régimen de "flujo de órdenes igual"? No. Lo que aprendes es cómo se comporta la programación bajo condiciones de paridad.