> ## 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 SPI

> Liquidación ininterrumpida, rotación de certificados, manejo de contingencias y el modelo de reconciliación detrás de Lerian SPI para operaciones 24/7.

Lerian SPI trabaja en torno a dos realidades operativas de Pix. Pix liquida en tiempo real, las 24 horas del día, y el BACEN confirma cada liquidación de forma asíncrona. El despachador de devoluciones intenta registrar un `pacs.004` saliente antes de enviarlo, pero un fallo de registro se trata como best effort y no bloquea necesariamente el despacho.

## Liquidación ininterrumpida

***

Pix liquida individual e instantáneamente, sin interrupción. No hay una ventana diaria que abrir o cerrar. En su lugar, dos superficies adyacentes usan sus propios períodos de referencia. La programación de **Pix Automático** (agendamento) da a cada instrucción una hora de ejecución solicitada y una última fecha en que puede liquidar. Los reportes de la **Conta PI** usan un período de referencia de saldo o extracto, con una ventana de fechas de hasta 92 días.

## Rotación de certificados

***

El riel gestiona el certificado de firma de Pix a través de su ciclo de vida. Subes el `.cer` público. Desactivas un certificado que retiras. El riel rechaza una clave privada subida, fail-closed. El riel almacena solo las huellas SHA-256 y los metadatos públicos, de modo que una respuesta nunca expone material de clave. El riel emite una señal de días hasta la expiración, para que los operadores puedan actuar antes de que un certificado expire.

## Contingencia y recuperación

***

Cuando un pago se atasca, el riel expone solo las acciones que puede ejecutar:

* Una vista de **operaciones atascadas** lista los ítems que necesitan atención.
* Una evaluación de **elegibilidad de recuperación** decide si una operación es recuperable.
* Una **acción de recuperación** o una **resolución manual** despeja una operación elegible.
* Un flujo de **aprobaciones de autorización manual** controla las operaciones que necesitan una aprobación explícita antes de proceder.
* Un trabajo de **exportación de evidencia** empaqueta el registro de una operación para auditoría o disputa.

El listado declara, por fila, cuáles verbos puede ejecutar realmente el riel sobre ella. Un verbo que el riel no puede ejecutar en una fila está ausente de esa fila, así que el panel nunca ofrece una acción que será rechazada. Todo verbo exige una justificación del operador, que se persiste junto con el resultado.

Una devolución que nunca recibió respuesta tiene su propia salida. Un `pacs.004` sin respuesta de estado deja la devolución esperando indefinidamente, reteniendo holgura del techo de la suma que el Pix nunca podrá reutilizar y —en la superficie de devolución integral— bloqueando cualquier devolución posterior de ese Pix. Un operador resuelve esa devolución como no realizada, y el riel entonces libera la holgura que retenía.

El riel rechaza esa resolución salvo que su propio estado pruebe que el dinero nunca salió. Liberar el techo de una devolución cuyo desenlace es desconocido es justamente cómo un Pix termina devuelto dos veces, así que una devolución no comprobada permanece como está y la liberación no se ofrece.

## Reconciliación

***

Las capacidades de reconciliación operan en varios granos. La reconciliación DICT incremental y completa automática se ejecuta solo cuando `SCHEDULER_ENABLED=true` y sus respectivas feature gates están habilitadas, y una ejecución puede fallar. La limpieza de claves huérfanas y el procesamiento de plazos de reivindicaciones son flujos separados:

* La **reconciliación del DICT** puede ejecutarse de forma completa o a partir de la lista de eventos del BACEN.
* La **limpieza de claves huérfanas** puede eliminar las claves que dejó atrás un flujo interrumpido.
* El **procesamiento de plazos de reivindicaciones** puede avanzar o cerrar las reivindicaciones contra sus ventanas del BACEN.

## Invariantes de liquidación

***

Tres invariantes se sostienen en todo momento:

* **Un submit es despacho, no confirmación.** Un submit aceptado confirma solo que el riel aceptó el despacho. Para un pago saliente, la respuesta de estado `pacs.002` entrante aplica `COMPLETED` o `REJECTED` y proyecta los campos de BACEN literalmente. Un `pacs.008` entrante se registra como pendiente y se completa o se rechaza mediante la decisión de fondeo del cliente autenticado. Lo mismo aplica a una devolución: un `pacs.004` que el riel aceptó para despacho lo concluye la respuesta de BACEN, nunca el envío.
* **La identidad de una devolución se registra, no se deriva.** El riel almacena cuál superficie creó cada devolución, así que una devolución parcial identificada por un valor elegido por el cliente nunca se lee como la devolución integral de su Pix.
* **El riel es neutral respecto al dinero.** Reenvía los montos declarados exactamente y no calcula posición ni saldo. El consumidor de tu ledger registra cualquier posición contable.
