> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Operar Lerian SILOC > Operar Lerian SILOC: ventanas de liquidación, certificados ICP-Brasil, ingestión SFN optativa, deduplicación durable, monitoreo, alertas y auditoría. SILOC liquida sobre una base **diferida neta, en días hábiles**, y Lerian SILOC opera dentro de esa única realidad operativa. El servicio mantiene abierta la conexión del gateway y, cuando la ingestión SFN está habilitada, despacha sus mensajes compatibles. No mantiene posición contable. ## Ventanas de liquidación *** SILOC liquida sobre una base diferida neta multilateral, en días hábiles. Nuclea define las ventanas diarias de liquidación para los productos de boleto y de tarjetas. Lerian SILOC registra y aplica los mensajes de orden de transferencia que abren, avanzan, reconcilian y cierran el estado de su ciclo; no calcula la posición monetaria neta. ## Certificados regulados *** Registras los certificados del gateway como un **certificado público más una referencia de custodia externa**. El servicio no conserva clave privada alguna. Cuando registras un certificado, el servicio analiza su sujeto, serie y ventana de validez. Revocas el certificado por la API cuando lo retiras. Un estado de **credencial deshabilitada** detiene el gateway. Un certificado deshabilitado o revocado fail-closes la conexión en lugar de correr con credenciales inválidas. ## Contingencia y recuperación *** La ruta de ingestión SFN tiene resultados definidos bajo falla; no promete que cada frame se conserve ni que cada operación tenga un único efecto de extremo a extremo: * La ingestión SFN es optativa. `SFN_INGEST_ENABLED` tiene el valor predeterminado `false`; habilítala explícitamente antes de que se inicie el consumidor. * Un envelope que no se puede decodificar, un mensaje decodificado sin `BCMSG.NUOp` no vacío o un `CodMsg` no compatible —incluido `PAG0101`— no sigue el despacho normal. Una falla no reintentable sigue la ruta de mensajes muertos y se confirma para que la partición pueda avanzar. * Una falla de despacho reintentable queda sin confirmar. Con commits de fuente seguros por offset, se vuelve a leer después de un reinicio desde el último offset confirmado; una falla transitoria persistente puede bloquear su partición hasta el reinicio. * La entrega y el despacho son **al-menos-una-vez**. Para un mensaje decodificado y compatible, el servicio consulta la deduplicación durable mediante **(`BCMSG.NUOp`, `CodMsg`)** antes de despachar y escribe el registro de mensaje procesado solo después de que el despacho tenga éxito. No es deduplicación solo por id de mensaje ni una garantía incondicional de exactamente una vez de extremo a extremo. ## Reconciliación *** La reconciliación se ejecuta en varios granos para que el estado de la conexión nunca se desvíe: * **Ledger de deduplicación de mensajes procesados.** Para mensajes decodificados y compatibles con NUOp no vacío, el ledger usa la clave compuesta (`BCMSG.NUOp`, `CodMsg`) y la registra solo después de un despacho exitoso. Los mensajes no decodificados o no compatibles no reciben un registro de mensaje procesado. * **Feed de auditoría del procesamiento de mensajes.** El feed de auditoría lista mensajes SFN compatibles que el servicio despachó. * **Estado por participante e historial de estado.** Cada participante lleva su estado operativo. El servicio conserva cada cambio de estado como una entrada de historial de eventos de estado. ## Monitoreo, alertas y auditoría *** Lerian SILOC expone una superficie de operador para observar ciclos de liquidación OT, salud de la conexión y del relay, y estado de los participantes. Las superficies de ciclo y reconciliación informan estado registrado y conjuntos de reconciliación; no calculan cifras agregadas de posición en lectura. * **Ciclos de liquidación OT.** [`GET /api/v1/siloc/cycles`](/es/reference/rails/siloc/list-cycles) y [`GET /api/v1/siloc/cycles/{cycleId}`](/es/reference/rails/siloc/get-cycle) listan e inspeccionan ciclos. [`GET /api/v1/siloc/cycles/{cycleId}/reconciliation`](/es/reference/rails/siloc/get-cycle-reconciliation) devuelve el resultado de la reconciliación, y [`GET /api/v1/siloc/cycles/{cycleId}/recalculations`](/es/reference/rails/siloc/get-cycle-recalculations) devuelve la cadena de rondas de recálculo del ciclo, incluyendo el cierre de la ventana de complemento/depósito de cada ronda. * **Instrucciones de liquidación.** [`GET /api/v1/siloc/settlement-instructions`](/es/reference/rails/siloc/list-settlement-instructions) y [`GET /api/v1/siloc/settlement-instructions/{instructionId}`](/es/reference/rails/siloc/get-settlement-instruction) devuelven las obligaciones de cada ciclo. [`POST /api/v1/siloc/rocs`](/es/reference/rails/siloc/ingest-roc) ingiere una revisión semántica de ROC que supersede los valores previos del ciclo. * **Alertas operacionales.** [`GET /api/v1/siloc/alerts`](/es/reference/rails/siloc/list-alerts) devuelve un feed activo por defecto, paginado por keyset. Los tipos de alerta incluyen `WINDOW_CLOSING` (un plazo de depósito/complemento se aproxima), `RECALCULATION` (un ciclo está en una ronda de recálculo), `RELAY_DOWN`, `CONNECTION_DOWN`, `CERTIFICATE_EXPIRY` y `SCHEDULE_CHANGE` (un operador registró un anuncio de agenda por contingencia). Las alertas se limpian de forma atómica cuando la condición subyacente se resuelve —por ejemplo, un ciclo que liquida limpia su alerta `RECALCULATION` en el camino de liquidación. Pase `activeOnly=false` para incluir alertas desactivadas como historial. * **Trilla de auditoría.** [`GET /api/v1/siloc/audit-records`](/es/reference/rails/siloc/list-audit-records) devuelve una lectura literal y paginada de la trilla de auditoría —por ejemplo, para exportar el registro de una acción de operador o de un cambio de estado de participante. Los límites `from` y `to` son instantes RFC3339 (los valores de solo fecha se rechazan). ## Agenda y contingencia *** La cuadrícula de ciclos OT y el calendario de días hábiles son artefactos compilados en el servicio —la API los proyecta de forma literal; nunca parsea un cable de agenda de Núclea. * **Calendario y ventanas.** [`GET /api/v1/siloc/schedule/calendar`](/es/reference/rails/siloc/get-business-day-calendar) devuelve el calendario de días hábiles, y [`GET /api/v1/siloc/schedule/windows`](/es/reference/rails/siloc/list-schedule-windows) devuelve la grilla canónica de ventanas OT ya compilada —un artefacto estático, no una lectura por día, que se sirve incluso con el datastore caído. * **Cambios de agenda por contingencia.** [`POST /api/v1/siloc/schedule/changes`](/es/reference/rails/siloc/record-schedule-change) registra un anuncio de contingencia que el operador recibió por fuera del canal, de parte de Núclea. El cuerpo lleva `reason` (≤500 caracteres), `origin` —el canal que anunció o la referencia de origen (≤256 caracteres)—, `effectiveAt`, el instante RFC 3339 anunciado en que el cambio entra en vigor, y un `windowSeq` opcional que nombra la ventana canónica afectada. El registro es **solo-agregar**: un anuncio posterior nunca reescribe uno anterior. El anuncio más nuevo sí se convierte en la única alerta `SCHEDULE_CHANGE` activa —registrar uno limpia la alerta previa y levanta una nueva cuyo plazo es `effectiveAt` literal. [`GET /api/v1/siloc/schedule/changes`](/es/reference/rails/siloc/list-schedule-changes) devuelve los cambios registrados, del más nuevo al más antiguo. Registrar un cambio de agenda por contingencia: ```bash theme={null} curl -X POST https://siloc.example.com/api/v1/siloc/schedule/changes \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "reason": "Núclea extendió la ventana OT en 30 minutos", "origin": "Núclea correo ref 2026-07-22/01", "effectiveAt": "2026-07-22T18:30:00-03:00", "windowSeq": 2 }' ```