WEXP Coverage pregunta quién controla la captura de acciones

Resumen

El borrador individual WEXP Coverage, presentado el 23 de octubre de 2026 por Mikhail Sergeev, separa la autenticidad de un recibo de la cobertura de todas las acciones de un conjunto definido. Su perfil PostgreSQL propone un caso comprobable: incorporaciones confirmadas a un libro de acciones durante una época cerrada.
El punto de decisión recae en quien utiliza el resultado. Debe saber qué supuesto de captura aceptó, quién autorizó ese supuesto y si el responsable del libro podía sacar acciones del circuito.

El asiento que el auditor nunca vio

Un auditor puede revisar cada firma de una carpeta y aprobarlas todas. La operación más interesante quizá no está en la carpeta. El borrador WEXP Coverage de Mikhail Sergeev ataca ese hueco con una pregunta que una firma no contesta: ¿qué prueba que todas las acciones del ámbito declarado llegaron a convertirse en registros y recibos?

El documento, fechado el 23 de octubre de 2026, no promete una prueba universal. Obliga a fijar el alcance, los cortes temporales, la identidad de las acciones y las premisas de captura. El IETF Datatracker lo identifica como Internet-Draft individual activo, sin cauce RFC. Esa condición importa: se examina una arquitectura propuesta, no una regla aprobada por el IETF ni una auditoría de una organización real.

El problema sí es real para cualquier comprador de registros verificables. Si una empresa controla el origen de los datos y también el informe que certifica su integridad, el informe puede ser internamente perfecto y externamente incompleto. El borrador coloca esa relación de control dentro de la evaluación, donde el lector puede verla.

Cinco conjuntos antes de sumar nada

El texto llama A a las acciones que ocurrieron dentro del ámbito. C recoge todos los recibos finales creados antes del corte de creación. R recoge los recibos disponibles para el destinatario designado antes del corte de entrega. Cv y Rv son las vistas que se entregan al evaluador. S es la vista de entradas del origen utilizada para estudiar A. La integridad de S y su cobertura de las acciones son cuestiones diferentes.

Una solicitud, una autorización, una invocación, una transacción confirmada, la creación de un recibo y su entrega no son un único acontecimiento. Una respuesta perdida después de la confirmación no borra la acción. Reenviar el mismo recibo no crea automáticamente otra. En cambio, emitir dos recibos distintos para una acción puede impedir una correspondencia exacta. El contrato de cada instalación debe decidir cuándo nace una acción y cuándo un recibo es final. Sin esa decisión, el total depende de la comodidad de la consulta.

El vocabulario propuesto cierra otras escapatorias. creation-complete pregunta si cada acción tiene un recibo final; creation-sound, si cada recibo responde a una acción; creation-exact, si la relación es uno a uno. Hay afirmaciones separadas sobre entrega, origen, correspondencia entre vistas suministradas y ausencia de acciones. Son diez identificadores. La palabra «completo» deja de funcionar como una manta que tapa todos los errores.

Un ejemplo sencillo muestra la diferencia. Dos exportaciones coinciden fila por fila. El evaluador puede afirmar que las dos vistas entregadas corresponden entre sí. Si el sistema de origen dejó escapar una acción antes de exportar, esa comparación no establece cobertura. El borrador exige distinguir una vista vacía que se leyó por entero de una vista no disponible por fallo de consulta. Un sello firmado sobre una lista vacía autentica esa lista; no demuestra que el mundo estuviera vacío.

El supuesto tiene dueño

El proyecto clasifica cada premisa como comprobada, asumida, desconocida o refutada. Cuando una premisa se acepta como supuesto, deben constar la política, la autoridad que la aceptó, su motivo y su alcance. «Todas las acciones están capturadas» no puede ser el supuesto que prueba que todas las acciones están capturadas. La instalación ha de explicar rutas de entrada, escritores, fases de vida, fallos y posibles vías de elusión.

Aquí la auditoría pasa de la criptografía al gobierno. Un administrador privilegiado puede alterar el origen. Una restauración puede presentar una historia antigua; una bifurcación, solo una de varias historias. Un recibo puede salir por un camino ajeno al libro. El borrador advierte que dos sellos coincidentes, dos organizaciones o dos claves distintas no prueban por sí mismos que no exista una vía oculta. La independencia de control no aparece al duplicar firmas.

Uno de sus casos construidos permite que convivan una derivación positiva basada en un supuesto de captura y un contraejemplo que acredita una acción omitida. El resultado conserva ambas y marca la afirmación como not-established por conflicto. El evaluador no puede cambiar la política para esconder el contraejemplo. Se trata de una disciplina institucional escrita como regla técnica: quien autorizó la confianza en el controlador no adquiere permiso para borrar la prueba contraria.

Tres cierres para una afirmación pequeña

El perfil pg-ledger/0.2.0 define la acción de forma estrecha: una incorporación confirmada a un libro nombrado, en un lote PostgreSQL 18 con una sola primaria. No convierte ese asiento en un pago realizado ni en una orden ejecutada fuera de la base de datos. Para eso haría falta definir y validar otro vínculo.

Cada incorporación y cada sello bloquean la misma fila de época. Tres barreras confirmadas cierran sucesivamente la admisión de acciones, la creación de recibos finales y la admisión del destinatario. La finalización espera al primer cierre; la publicación espera al segundo. Después del tercero puede leerse una instantánea completa de las vistas pertinentes. El número de secuencia y la hora de pared no prueban por sí solos el orden de confirmación. Los intentos duplicados y las variantes contradictorias permanecen visibles.

La arquitectura concreta el significado de «todas» dentro de ese lote. Su precio es una lista de dependencias: funcionamiento correcto del host y de PostgreSQL, almacenamiento íntegro, separación de funciones, ausencia de emisión anticipada o de rutas paralelas, exportación completa autenticada y claves y política estables. Un administrador con privilegios suficientes, una restauración, una bifurcación o una emisión ajena al libro pueden romper la base. Si el controlador puede cambiar la población antes de cerrarla, el sello llega demasiado tarde.

El borrador WEXP Core evalúa afirmaciones de contenido sobre objetivos de ejecución concretos. Coverage evalúa la población. El texto imagina 99 evaluaciones correctas junto a una centésima acción establecida sin recibo en un conjunto cerrado de 100. Las 99 conservan su validez local. La falta de la última exige prueba positiva de que pertenece al conjunto y una búsqueda negativa exhaustiva del recibo; el número 99, aislado, tampoco demuestra una omisión. Es un ejemplo lógico, no una tasa observada.