> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rem.money/llms.txt
> Use this file to discover all available pages before exploring further.

# How REM works

> The product loop and the five modules that make up REM.

## The product loop

Every REM deployment runs the same loop, whatever the network or workflow:

```text theme={null}
Observe authorised activity
  → establish canonical history and state
  → normalise financial meaning
  → enforce policy and approvals
  → execute durable workflows
  → reconcile every system
  → retain evidence and exceptions
```

The promise is correctness across the full lifecycle, not fast notifications.

## Modules

REM is delivered as five modules. A first engagement typically uses Edge, Model, Sync, and Reconcile; Flow is added when the workflow needs automation or customer-controlled transactions.

<CardGroup cols={1}>
  <Card title="REM Edge" icon="plug">
    Connectors for ledgers, custody systems, and enterprise sources, deployed privately, in a VPC, on-premises, or embedded in a vendor's product. Edge handles authorised access, checkpoints, provenance, gap detection, reorgs and finality, corrections, and replay.
  </Card>

  <Card title="REM Model" icon="cubes">
    Canonical financial objects and lifecycle semantics. A transfer, deposit, coupon, settlement, or redemption means the same thing in every downstream system, regardless of the network it came from.
  </Card>

  <Card title="REM Sync" icon="arrows-rotate">
    Delivery through APIs, webhooks, Kafka-compatible streams, databases, warehouses, files, and enterprise schemas.
  </Card>

  <Card title="REM Flow" icon="diagram-next">
    Durable automation across services, databases, approvals, and customer-controlled transactions, with retries, idempotency, timeouts, and execution history.
  </Card>

  <Card title="REM Reconcile" icon="scale-balanced">
    Continuous comparison across ledger, custody or provider, bank, and internal books, with explainable breaks, an investigation lifecycle, and recovery evidence.
  </Card>
</CardGroup>

## The first offer

REM sells one embedded integration backend for one live workflow:

```text theme={null}
Authorised ledger or application view
  → REM connector
  → canonical financial events and state
  → customer API, stream, database, or accounting system
  → reconciliation, exceptions, and audit trail
```

The engagement has to measurably reduce integration time, operational errors, reconciliation breaks, or maintenance.

## How REM expands

Once the first workflow is live, REM grows along a fixed sequence:

<Steps>
  <Step title="Connectivity">
    One application connected to one enterprise system.
  </Step>

  <Step title="Semantics">
    Stable financial objects and lifecycle events.
  </Step>

  <Step title="Operations">
    Reconciliation, exceptions, evidence, and materialised state.
  </Step>

  <Step title="Automation">
    Policy, approvals, durable workflows, and controlled execution.
  </Step>

  <Step title="Lifecycle">
    Asset servicing and obligation management.
  </Step>

  <Step title="Ecosystem">
    Templates, OEM distribution, and partner-built modules.
  </Step>
</Steps>