Del enrolamiento a una cronología verificable
1. Enrola un firmante en su ámbito
Con tu cuenta en línea, crea el expediente del proyecto, registra una sucursal y enrola una clave pública. Los eventos quedan ligados a esa cuenta, proyecto, sucursal y dispositivo lógico.
2. Firma y conserva eventos pendientes
En navegadores compatibles, prepara eventos declarados en la cola local cifrada. La firma Ed25519, el número de secuencia y la referencia hash anterior forman el sobre que se enviará al servidor.
3. Sincroniza y revisa excepciones
La sincronización requiere estar en línea con la misma cuenta. El ACK se entrega tras registrar el evento; ante una respuesta incierta conserva la referencia y consulta o reenvía el mismo sobre, sin cambiar la cadena ni crear otro evento silenciosamente.
Configuración actual del servicio
Las capacidades publicadas describen el servicio, no conceden permisos a tu cuenta ni prueban disponibilidad inmediata. La operación requiere un piloto vigente para el proyecto; la capacidad local depende además del navegador y de la clave conservada por el usuario.
Recepción de eventos declarados firmados
Consultando…Enrolamiento de claves públicas por sucursal
Consultando…Cronología privada de eventos recibidos
Consultando…Cotejos explicables de datos declarados
Consultando…Exportaciones privadas JSON y TXT
Consultando…Firma de evidencia ViciousByte
Consultando…Control de equipos físicos
Control de hardware no implementadoVerificación de hechos físicos
No verifica la realidad físicaCertificación de autenticidad fiscal
No verifica autenticidad fiscalEjecución de pagos
Ejecución de pagos no implementada
Qué respalda cada evidencia
El enrolamiento de una clave pública no demuestra por sí solo su posesión: se comprueba al recibir un evento firmado válido. La firma de eventos verifica una clave enrolada y su contenido declarado. La firma opcional de ViciousByte cubre un manifiesto con hashes del expediente, los eventos y el informe; la exportación conserva esos objetos para poder recalcular sus hashes. No firma directamente todo el cuerpo ni certifica su verdad física. El panel adjunta o descarga la atestación; no afirma una verificación criptográfica local.
Secuencia y cadena hash permiten verificar continuidad dentro de un firmante y detectar conflictos del sobre recibido. Una cola vacía o una cadena aceptada no demuestran que todos los hechos físicos fueron registrados. Un evento pendiente todavía no tiene confirmación del servidor.
La cronología conserva el ámbito, las referencias y los tiempos declarados junto al momento de recepción del servidor. Las referencias de tickets, CFDI y lecturas se interpretan como datos aportados, no como pruebas de pago, timbrado fiscal ni medición certificada.
Las excepciones explican diferencias o relaciones observadas en los datos recibidos, según las reglas publicadas. La cobertura es acotada; falta de evidencia o ausencia de una excepción no equivale a una auditoría física completa ni a una certificación de cumplimiento.
Cola local cifrada: custodia y límites
El panel utiliza un vault AES-GCM con clave aleatoria que conserva el usuario. La clave privada Ed25519 y la cola pendiente se guardan cifradas; pueden persistir tras recargar o cerrar sesión mientras el navegador conserve esos datos. No se promete almacenamiento perpetuo.
Desbloquear el vault es una acción local: no inicia sesión, concede acceso al proyecto ni autoriza APIs. Para sincronizar se exige la misma cuenta autenticada en línea y el acceso que confirme el servidor; retirar un dispositivo puede impedir recibir su cola pendiente.
Una copia del vault y su clave pueden clonar el firmante: no se afirma una identidad única de hardware. Guarda ambos bajo tu custodia. Si se pierde la clave o se borran los datos locales, no se garantiza recuperar la clave privada ni los eventos que aún no llegaron al servidor.
La cola se sincroniza mediante acciones explícitas del panel abierto. No se promete ejecución en segundo plano, autonomía sin sesión o conexión, compatibilidad universal de navegador ni integración con lectores, cajas o dispositivos físicos.
Expediente, capacidad y presupuesto publicados
Se reciben sobres de eventos declarados con firma adicional a la autenticación habitual. No se envían comandos a equipos, no se consultan conectores externos y no se ejecutan pagos o movimientos de fondos.
El acceso requiere unidades branch_event del piloto, independientes de otros servicios. Los presupuestos de admisión y la capacidad del expediente son límites operativos separados; no son precios ni cargos automáticos.
Los límites vigentes no pudieron confirmarse. Consulta el catálogo o el panel; no se presupone capacidad, retención ni permiso de sincronización.
Ámbito privado y vencimiento fijo
Sucursal, dispositivo lógico y eventos pertenecen a la misma cuenta y proyecto, incluso para administradores. Incluye solo datos que tengas derecho a procesar y evita contenido sensible innecesario en tickets, referencias o lecturas.
Retirar una sucursal o revocar un dispositivo impide nuevos eventos en ese ámbito y conserva el historial dentro del plazo del expediente. No libera el cupo histórico ni acredita el origen físico del firmante.
Eliminar el expediente o alcanzar su vencimiento bloquea sus lecturas y nuevas publicaciones, y encola la purga asíncrona de datos del servidor. El borrado remoto no puede borrar copias locales desconectadas: su custodia y eliminación se gestionan en el navegador. Un expediente vencido no revive ni extiende su plazo al sincronizar.
Branch Audit requiere un piloto explícito aprobado para tu cuenta y proyecto, con presupuesto propio. Los planes de otros servicios no lo habilitan. Solicitar acceso registra interés pendiente de revisión; no concede permisos ni inicia pagos.
Solicitar acceso piloto
Registra una solicitud de Auditoría de sucursales para tu cuenta. Esto no crea una suscripción, activa permisos ni ejecuta un pago.