Concepts & glossary
The terms that recur across the guides and the API, and mean the same thing everywhere — because once case and task become interchangeable, nobody can say what is still owed or who owes it.
These are the terms that recur across the guides and the API, and they mean the same thing in each. A case and a task are different objects with different owners, and once two people use the words interchangeably, neither of them can say what is still owed on a borrower’s matter or who owes it.
Eleven words carry the servicing model
Learn these eleven and the servicing guides need no translation:
| Term | Meaning |
|---|---|
| Case | The lasting record of one customer or merchant matter — a question, delinquency, bankruptcy notice, cease request, dispute, or operational issue. It owns why the matter exists and what must be true before it closes. |
| Task | A single unit of work, created by a workflow, an interaction, a case control, a system monitor, an AI finding, or an action result. It reaches an eligible worker through a queue. |
| Queue | A prioritized container that routes work to eligible workers by queue membership, task type, channel, case type, priority, or restriction. Specialist capability is a queue, not a skills attribute. |
| Interaction | An inbound, outbound, or externally logged communication with a customer or authorized party. It is distinct from a task, provider event, and resulting action. |
| Action request | A case-linked request opened only when the operation that owns it needs approval or genuinely becomes deferred, manual, external, or unavailable. Allowed work executes directly; the authoritative domain still owns the result. |
| Compliance decision | The structured result of evaluating a proposed contact or action against policy and known facts: allowed, allowed with warning, approval required, blocked, or missing facts. |
| Promise to pay | A customer commitment with one or more amounts and dates, evaluated only against authoritative posted payment facts. It never moves money by itself. |
| Evidence | Material that supports a decision or outcome: documents, interactions, notes, snapshots from the system of record, compliance decisions, and AI analysis. |
| Worker | A human agent, an AI agent, or a system monitor. All three perform or prepare work under the same permissions, compliance, and audit. |
| Work packet | The bounded context, policy, allowed tools, prohibited actions, and approval path assembled for a worker on a task. An AI agent sees and does only what its packet grants. |
| Autonomy | The action-specific level an AI may observe, assist, prepare, or execute within policy. It is capped by risk and earned by version-specific evidence. |
Three of those are easy to blur. An interaction is what was said; a task is one unit of work an agent or a person owes; an action request exists only where the owning operation could not simply proceed. Blur the first two and a logged call starts reading as completed work nobody actually did. Blur the last two and every allowed operation grows an approval step it was never supposed to need.
The old words name nothing in the API
The Lending Core under /v1 has vocabulary of its own, and four older phrasings name nothing here: “loan actions,” “payoff quotes,” “form submissions,” and “reconciliation items.” An integration written against “payoff quotes” goes looking for a resource, a quote ID, and a quote lifecycle, and spends a day discovering that a payoff is a block computed on each read.
| Term | Meaning |
|---|---|
| Governed command | A ledger operation — interest waiver, write-off, charge-off, re-age, re-amortize, and their undos — executed as POST /v1/loans/{loanId}/transactions?command=… with exact domain permission, valid case context, governance records, and maker-checker. |
| Command receipt | The { resourceId, changes } body a Lending Core mutation returns. Read the resource afterward for its current state. |
| Payoff projection | The payoff block of the loan summary, computed on each read for a good-through date. Nothing is stored: there is no quote ID and no quote lifecycle. |
| Form entry | A set of structured answers captured against one customer or loan under a published form definition, governed by permissions derived from the form key. |
| Reconciliation exception | A tracked difference between provider events, money intents, and the ledger — stuck-before-submit, settled-not-posted, and similar — worked through the recon-exceptions routes. |
| Document / Note | Lending Core records linked to customers and loans, with scanning, history, revisions, and redaction. Distinct from servicing case documents and case evidence under /v1/servicing. |
LendEasy-Tenant |
The required header naming the tenant on every API call. |
LendEasy-Case |
The header carrying an open case reference on human servicing mutations when case management is enabled; see Access control. |
Four terms describe how it is put together
Four more name the shape of the platform rather than anything inside it, so they turn up wherever a guide explains why something is allowed. See System architecture.
| Term | Meaning |
|---|---|
| Control plane | An operating layer that holds a desired state, observes authoritative state, reconciles the difference, governs execution, and records every decision. |
| System of record | The lending core that owns loans, balances, schedules, payments, and accounting — natively the LendEasy Lending Core. With the additional bring-your-own-core additional option, LendEasy references your system and never becomes the financial record itself. |
| Restriction | A named hold — payment, autopay, disbursement, collections, communication, or SCRA/MLA protection — applied at customer scope, optionally to one loan, and enforced at execution time until cleared. |
| Drift | A divergence between LendEasy’s operational state and the authoritative state in your core, surfaced as work rather than hidden. |