Conceptos

Cómo Onigiri conserva la historia de un contrato

Un contrato no es una foto: vive. Se prorroga, se le hace una adenda, se cede a otro arrendatario, sube la renta al cumplirse un hito, se finiquita. Onigiri modela esa vida como una cadena de eventos y garantiza que, pase lo que pase, nada de lo que un día supimos del contrato se pierda.

Un contrato es una cadena de eventos

En el Historial del contrato marcas cada cambio: una prórroga corre el vencimiento, una adenda cambia la renta, una cesión cambia el arrendatario, un finiquito lo cierra. Cada uno queda registrado con su antes → después, en orden cronológico.

Sobre esa cadena, Onigiri proyecta el estado vigente: toma el contrato original y le aplica los cambios en orden, dejando ver lo que vale hoy. La proyección es una vista, no una sobreescritura: recalcula el vencimiento, la renta vigente y los avisos sin borrar el punto de partida. Si quitas un evento, el contrato se re-proyecta y vuelve al estado que tenía sin él.

Las cuatro capas que garantizan que nada se pierde

Si un contrato se borra, se reasigna o cambia de manos, los datos siguen ahí. Cuatro capas independientes se respaldan entre sí:

• El documento fuente, inmutable. Cada PDF que subes se guarda tal cual, direccionado por su contenido, junto al texto que leyó el modelo. Aunque cambie todo lo demás, el documento original es siempre re-consultable y re-extraíble.
• La cadena de eventos. Los cambios que marcas viven junto al contrato como una lista de eventos tipados, con su antes→después. La proyección los reduce al estado de hoy sin destruir la base.
• La papelera. Borrar un contrato no lo elimina: hace una copia de seguridad y lo manda a una papelera reversible antes de tocar nada de lo que dependía de él.
• La lectura completa del anexo. Cuando un evento adjunta un documento, Onigiri guarda con ese evento la lectura completa del PDF — incluidas cláusulas y datos que hoy no mostramos. Es una cápsula inmutable: si mañana empezamos a usar un campo nuevo, ya lo tenemos, sin volver a subir ni releer nada.

Marcar un cambio no es lo mismo que corregir la base

Son dos caminos distintos, a propósito:

• Marcar un cambio (Historial) agrega un evento nuevo a la cadena: el contrato original queda intacto y el estado vigente se recalcula. Es lo que usas cuando el contrato efectivamente cambió: se renovó, se le hizo una adenda, se cedió.
• Corregir la base es un flujo separado: se usa cuando un dato del contrato original quedó mal leído. Ahí sí editas el valor de origen — y esa corrección alimenta el aprendizaje del sistema —, pero no inventa un evento que nunca ocurrió.

Cuando adjuntas un anexo, lo leemos — pero tú confirmas

Una renovación marcada como contrato nuevo necesita su PDF: es un instrumento legal nuevo. Al adjuntarlo, Onigiri lo custodia y lo lee con la misma lectura completa que usa al cargar cualquier contrato, para pre-llenar las fechas del evento. Tú las confirmas o las corriges antes de marcar.

El punto fino: esa lectura no pisa nada. El estado vigente se computa de los campos tipados que tú confirmas, no del texto crudo del anexo. Por eso la lectura del anexo pasa por los mismos controles de calidad que el resto de la plataforma y no debilita la trazabilidad: cada cifra sigue viniendo con su respaldo, y lo que se guarda entero (la cápsula de lectura completa) queda como reserva, no como una afirmación sobre lo vigente.