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

# Integrating with Lerian Consignado — Dataprev

> How the gateway integrates — the two commands it consumes from the credit engine, the five business facts it emits, its sink-agnostic outbox delivery, the absence of direct ledger and webhook coupling, and its wire and idempotency semantics.

Lerian Consignado — Dataprev is **event-first** at its platform edge. It consumes commands from the credit engine and emits business facts; it makes no direct ledger calls and hosts no webhook consumers. Its authoritative contract is the event stream, not its REST surface.

## Commands it consumes

***

The gateway consumes **two commands** from the credit engine, carried as events over the platform's streaming backbone:

* a **margin request**, asking for a worker's available payroll margin;
* an **averbação request**, asking to register a signed contract with Dataprev.

A command that decodes but is **missing its identifying key** — for example the worker's CPF — is terminal: it is dead-lettered rather than relayed to Dataprev.

## Facts it emits

***

The gateway emits **five business facts**:

* the fetched **margin** for a worker;
* an **averbação-confirmed** result;
* an **averbação-rejected** result;
* a **proposal-accepted** signal, telling the downstream lending system to originate;
* a **reconciliation** record — one per escrituração or settlement record.

Every fact carries a single, package-wide schema version, stamped identically across all five rather than versioned per event.

## Sink-agnostic delivery

***

The gateway writes every fact to a **transactional outbox** and relays from there. It owns **no per-destination routing**: a downstream streaming hub decides which system receives each fact. The same fact can fan out to a ledger, a reconciliation store, or a lending system without the gateway knowing or caring who consumes it.

## No direct ledger or webhook coupling

***

The gateway makes **no direct Midaz calls** and hosts **no webhook consumers**. Off-platform borrower contact is out of scope: the **proposal-accepted** fact is the handoff boundary, after which the downstream lending system owns origination and any borrower communication.

## On the wire

***

* **Money and rates cross as decimal strings**, never floating-point, so no precision is lost in transit.
* **Timestamps are UTC, RFC 3339.**
* **No CPF crosses the reconciliation fact.** This is enforced by construction: the reconciliation record types carry no CPF field, the CPF present in the escrituração source is dropped at the normalizer, and tests assert the serialized payload contains no CPF. The **contract number is the match key**, so no personal identifier is needed downstream. (The margin and proposal-accepted facts *do* carry a CPF, because each is keyed to a specific worker or proposal.)
* The CEF **repasse** settles **per daily movement, not per contract**, so bank-side reconciliation keys on the transfer handle rather than the contract number.

## Delivery semantics

***

* **Idempotent by immutable subject.** Each record and settlement carries an immutable identifier; reprocessing it is a no-op downstream.
* **At-least-once.** Events are delivered at least once; redelivery and restarts dedupe to a no-op.
* **Independent legs.** In reconciliation, the escrituração and repasse legs are processed independently — one failing never blocks the other.