> ## 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 Lerian Consignado integrates with your credit engine: the commands it consumes, business facts it emits, sink-agnostic outbox, and idempotency. 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. The event stream is its authoritative contract, not its REST surface. ## Commands it consumes *** The credit engine sends the gateway **four commands** as events over the platform's streaming backbone: * a **margin request** asks for a worker's available payroll margin * an **averbação request** asks to register a signed contract with Dataprev * an **exclusão request** asks to cancel a registered averbação * a **redirecionamento request** asks to redirect a contract to another creditor The exclusão and redirecionamento flows stay development-gated. Both adapters ship as fakes and stay disabled by default until homologation. A command that decodes but **lacks its identifying key** — for example the worker's CPF — is terminal. The gateway dead-letters it and does not relay it to Dataprev. ## Facts it emits *** The gateway emits **thirteen business facts**: * a discovered **loan-request offer** (solicitação) — relayed so the lender can decide whether to bid * the fetched **margin** for a worker * a **worker-absence alert** (afastamento) — one per alert element on a margin read * a **proposal-accepted** witness — the post-averbação read of what the rail registered * an **averbação-confirmed** result * an **averbação-rejected** result * a **contract-registered** booking handoff — the only fact that books a contract downstream * an **exclusão-confirmed** result * an **exclusão-rejected** result * a **reconciliation** record — one per escrituração or settlement record * an **employment-status report** for a worker * a **redirecionamento-confirmed** result * a **redirecionamento-rejected** result Facts share one package-wide schema version, with one exception: the proposal-accepted witness carries its own major version and publishes on a version-suffixed topic. A fact's catalog key is not its topic name. The topic is derived from the gateway's own application segment plus the fact's resource and event. See the [consignado event reference](/en/reference/events/consignado) for the full mapping. ## Sink-agnostic delivery *** The gateway writes every fact to a **transactional outbox** and relays from there — never straight to the broker, on any path. It publishes each fact to its own topic, but it owns **no consumer 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. The gateway does not know or care 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. Downstream lending systems own origination and any borrower communication. ## On the wire *** * **Money and rates cross as decimal strings**, never floating-point, which keeps full precision in transit. * **Timestamps are UTC, RFC 3339.** * **Worker identity travels inside reconciliation records, never in the log-visible reference.** The **contract number is the match key**, and each record may also carry the worker's CPF and matrícula: a record whose contract number matches nothing in the consumer's book is exactly the exception the feed exists to raise, so the record still names the worker it moved money for. The event subject stays a rail reference and never carries the worker. * 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.** The gateway delivers every event at least once. Redelivery and restarts dedupe to a no-op. * **Independent legs.** In reconciliation, the gateway processes the escrituração and repasse legs independently. A failure in one never blocks the other.