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

# Architecture

> Responsibilities and boundaries across REM's source, canonical, semantic, execution, and reconciliation planes.

## System model

```text theme={null}
NETWORK / SOURCE PLANE
Public EVM · private EVM · Tempo · custody · bank/internal sources
                              ↓
CONNECTORS + CANONICAL INGESTION
Authorised access · checkpoints · provenance · gaps · reorg/finality · corrections
                              ↓
CANONICAL JOURNAL + RAW ARCHIVE
Transactional outbox · durable event log · permitted object archive
                              ↓
PROCESSING / SEMANTIC PLANE
Decode · transform · enrich · canonical financial model · materialised state
                              ↓
CONTROL / EXECUTION PLANE
Policy · approvals · durable workflows · transaction intents · customer signing
                              ↓
INTEGRATION + RECONCILIATION
APIs · webhooks · DB · event bus · ERP · custody · internal ledger · evidence
```

The durable abstraction is **canonical ingestion → financial state and semantics → controlled execution → reconciliation**. The components underneath each plane are replaceable; the contracts between planes are not.

## Source connectors

Connectors (REM Edge) cover:

* Tempo Zones and public Tempo/EVM interfaces, as exposed;
* private and public EVM networks; and
* custody, provider, and internal-ledger APIs, files, and messages.

Every connector provides:

* live ingestion and bounded historical backfill;
* explicit participant authorisation and visibility scope;
* source-native ordering, offsets, and provenance;
* gap detection, resumable checkpoints, and deterministic replay;
* finality, reorganisation, correction, and compensation semantics;
* tenant isolation and permission-aware filtering; and
* a raw record sufficient to reprocess when policy permits.

<Note>
  An EVM archive node is not required just to detect transfers or ingest historical logs. It is required when a workflow needs arbitrary historical state or calls against old blocks. Blocks and logs, traces, and historical executable state are treated as separate requirements.
</Note>

## Canonical journal

Ingested records are published to a canonical stream through a transactional outbox, so database state and stream publication cannot silently diverge. The stream separates raw records, canonical records, reorgs, finality updates, and corrections.

REM always keeps the raw or source-faithful record. A derived warehouse is never the only copy.

## Decoding and semantics

The ingestion layer does not need to understand every ABI or business shape. Decoders are registered by network, contract or application, schema, and event signature:

```text theme={null}
raw record
  → generic protocol/ABI decoder
  → application-specific decoder
  → institution-specific financial transformation
  → canonical financial event
```

ABI decoding answers what the bytes mean technically. REM's semantic transformation answers what they mean to the customer's treasury, accounting, settlement, or reconciliation process.

## Canonical financial model

The canonical model (REM Model) is REM's semantic centre.

**Core objects**

| Group          | Objects                                                      |
| :------------- | :----------------------------------------------------------- |
| Sources        | `Network`, `SourceRecord`, `LedgerTransaction`               |
| Reference data | `Asset`, `Instrument`, `Account`, `Entity`, `Counterparty`   |
| Movements      | `Position`, `Transfer`, `Deposit`, `CashMovement`            |
| Obligations    | `Obligation`, `Settlement`, `Entitlement`, `CorporateAction` |
| Control        | `Policy`, `Approval`, `Workflow`, `ReconciliationBreak`      |

**Event envelope.** Every canonical event carries:

* stable event and causation identifiers;
* source provenance and authorisation scope;
* source, effective, observed, and processing timestamps;
* schema and mapping version;
* parties, accounts, assets, quantities, and status;
* finality and correction state; and
* trace links from the raw source through every downstream action.

Lifecycle events are prioritised by what the first design partner needs: deposit observation, finality, and credit; fixed-income issuance, transfer, coupon, maturity, and redemption; settlement; collateral; and reconciliation exceptions.

## Workflows and execution

REM Flow runs durable workflows for meaningful financial operations, not one heavy workflow per raw log:

```text theme={null}
HTTP · schedule · stream · onchain event · manual approval
  → durable workflow (policy, identity, approvals, idempotency)
  → HTTP / database / sub-workflow / transaction intent
  → transaction manager
  → signing interface (KMS, HSM, vault, or custodian)
  → network
  → receipt and finality observation
  → reconciliation
```

Workflows own retries, idempotent external effects, timeouts, recovery, and execution history. For onchain writes, the transaction manager owns intent persistence, nonce allocation, signing requests, submission, receipt tracking, and resubmission. REM policy owns fee and replacement rules, stuck-transaction handling, finality thresholds, and approval gates.

<Warning>
  All writes from a signing address pass through one nonce authority. The signer is an interface to the customer's KMS, HSM, or custodian. REM never becomes the custodian and never holds keys in production.
</Warning>

## Reconciliation

REM Reconcile compares canonical ledger or application state with custody and provider records and the customer's own ledger. It supports:

* configurable matching keys, tolerances, and time windows;
* missing, duplicate, late, out-of-order, and amount or status mismatch detection;
* finality- and correction-aware re-evaluation;
* explainable evidence and versioned rules;
* an investigation, ownership, resolution, and reopen lifecycle;
* metrics for completeness, aging, recurrence, and operational risk; and
* deterministic reruns after backfill or mapping changes.

## Private-ledger profile

On private ledgers, REM assumes participant-scoped data and authorised APIs, not a globally crawlable chain. REM Edge is deployed inside the customer's permitted boundary, and canonical history means the authorised participant view, with explicit provenance and visibility scope.

See [Deployment and security](/source/platform/deployment-and-security) for how private deployments are run.