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

# Operating Lerian SISBAJUD

> Operating Lerian SISBAJUD: per-institution isolation, reconciliation, permanent-block cadence, KEK and credential rotation, and envelope-encryption guarantees.

Lerian SISBAJUD fulfils and reports each order per institution, re-attempts permanent orders for weeks, and keeps personal data out of plaintext. It also proves every change it makes, because the law demands that proof.

## Per-institution isolation

***

Lerian SISBAJUD is **multi-tenant**. The tenant is the database-isolation boundary. Lerian SISBAJUD reads it from the `tenantId` claim, and single-tenant mode uses the explicitly supplied `DEFAULT_TENANT_ID`. It has no effective string default, so a usable single-tenant deployment must set a valid UUID.

The institution is a separate unit. Lerian SISBAJUD isolates each institution's orders, files, credentials, and encryption keys. One tenant can hold many institutions, and one deployment serves them all with no cross-institution visibility.

## Reconciliation

***

Reconciliation works at the grain of **one monitoring order against a ledger balance snapshot**. A **scheduled scan** compares outstanding orders to the ledger and records any gap it finds. An operator can also start a **manual reconciliation** on demand. A separate daily sweep closes monitoring orders that pass their ceiling or deadline, so nothing lingers past its legal life.

## Permanent-block cadence

***

Permanent orders re-attempt the block **on ledger balance-change events**. The CNJ **60-day reiteration ceiling**, or the order's court deadline, bounds each order. There is no scheduled reattempt pass. A deposit wakes the reattempt directly, and a daily expiry sweep closes orders whose deadline has lapsed.

## Credentials and key rotation

***

Two things rotate per institution, and both are administrative:

* **Connector credentials.** Lerian SISBAJUD uses these credentials to reach the ledger and the file-exchange channel. An operator **registers and rotates** them.
* **Key-encryption key (KEK).** An operator rotates the institution's KEK, and the rotation emits a `kek.rotated` event. Each record's **data key (DEK)** sits under the KEK. A rotation therefore bumps the active KEK version without re-encrypting any field. Data keys sealed under the previous version stay readable, and a background re-wrap then advances them to the new version. A rotation returns `SBJ-0007` / **409** when another rotation is already in progress.

  A rotation that commits but cannot be audited returns `SBJ-0002` / **500**. The KEK has already advanced, so this is **not retryable**. Retrying rotates a second time and widens the audit gap. Escalate and reconcile the audit trail against the `kek.rotated` event instead.

## Data protection

***

Lerian SISBAJUD protects personal data at rest:

* **Envelope encryption.** Each record carries its own data key, sealed under the institution's KEK with **AES-256-GCM**. Per-field additional authenticated data binds each ciphertext to one field and record, so no one can swap a ciphertext between fields or records.
* **Searchable tokenization.** A **blind index** supports exact-match indexing on fiscal identifiers (CPF/CNPJ) and the process number without plaintext storage. It does not replace account discovery: to query CRM, Lerian SISBAJUD decrypts the CPF/CNPJ only as needed and never logs it. Lerian SISBAJUD encrypts free text only and never tokenizes it. It does not tokenize monetary values, and it stores the order tables' monetary values as plaintext, not ciphertext.
* **Tamper-evident audit trail.** Lerian SISBAJUD appends every state change to a gap-free, cryptographically protected log. A per-event authentication code binds each entry to its position. **Merkle leaf hashes** let an operator verify the trail without decrypting any payload.
* **LGPD.** A subject-access request **exports** the data the institution holds on a subject. **Crypto-erasure** honours an erasure request. It destroys the record's key and tombstones its plaintext values, so the personal data becomes irrecoverable, while the audit record of the change survives.

## Contingency

***

Lerian SISBAJUD drives failed orders to a **FAILED** terminal state, not stuck in processing, and an operator can **reprocess** them. The **SLA-status** and **processing-statistics** views show where orders stand. Connector resolution **fails closed**. If the integration cannot safely resolve an account or a credential, it refuses the operation rather than act on an ambiguous target.

## HTTP surface

***

Orders arrive only by file, so the HTTP surface **submits no court orders**. Most endpoints are administrative and observational. `POST /remittance-files/notifications` is operational: it synchronously receives and parses a remittance object already delivered through the file-exchange channel. It does not accept an order payload. An operator can:

* list orders and files, and read the detail of a single order or file
* **reprocess** failed orders
* run a **reconciliation** and read its status
* view **SLA status** and **processing statistics**
* **verify** the audit trail
* handle **LGPD** requests: create them, resolve them, run an erasure, and export a subject's data
* register **non-compliance justifications**
* configure the institution, and **register or rotate** connector credentials