# Commerce and the five ledgers

Transactions define commitments, metering records consumption and ledgers record changes in value; fulfilment and acceptance are never replaced by a successful payment.

> Document ID: MYRILUM-DOC-ARCH-007
> Document type: concept
> Product: NOT_APPLICABLE
> Version: 0.1.0
> Region: GLOBAL
> Visibility: PUBLIC
> Publication: PUBLISHED_GLOBAL
> Content maturity: VALIDATED
> Governance: APPROVED
> Capability state: IN_DEVELOPMENT
> Availability: NOT_AVAILABLE
> Authorization: PUBLIC_INFORMATION
> Freshness: CURRENT
> Safety class: INFORMATIONAL
> Owner: Web3Capital Documentation Steward
> Approvers (assignment only; not approval evidence): Stephen
> Canonical authority: SRC-ARCHITECTURE-ATLAS-V2-2
> Source commit: 882487dec08bc4ca204510e166217478fa8f68ec
> Content digest: 5903ca6ac1d67a42b4a8bc14fe14c901776fbfb186a43be799928ac326342427
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /en/architecture/commerce-and-ledgers

<a id="overview"></a>

## What this map shows

![Commerce and the five ledgers diagram (A07)](/figures/atlas-v2-2/A07.png)

*MYRILUM architecture map v2.2 · A07 (public edition). Labels are in Chinese; every element is listed in English below. Select the diagram to open it at full size.*

This is MYRILUM's target architecture. It does not mean everything on the map is live; whether a capability can be used today is stated in “Current availability”.

Transactions make commitments explicit; metering records consumption; ledgers record changes in value; fulfilment and acceptance are never replaced by a successful payment.

Payment succeeded ≠ task completed; verification passed ≠ user accepted; contribution recorded ≠ cash or equity.

<a id="part-1"></a>

## Products enter a commercial contract

| Field | Value |
|---|---|
| Product version | Supported scope, inputs and outputs, licensing and after-sales |
| Offer and quote | Pricing unit, price version, tax fields and validity |
| Order and contract | Buyer, seller, terms, currency and fulfilment link |
| Payment and entitlement check | Existing entitlements can satisfy a task directly; no new purchase is forced for every task |

> **Exactly five ledgers** — 1 cash; 2 service credits; 3 entitlements; 4 resource usage; 5 contributions. Each is modelled separately and linked by stable identifiers.

<a id="part-2"></a>

## Fulfilment and value confirmation

| Field | Value |
|---|---|
| Entitlement grant and reservation | Purchase and usage rights are separate; actions still need authorization |
| Fulfilment request | Scope, service period, delivery standards and budget |
| Delivery, acceptance and disputes | An authorized user decides; verification cannot replace acceptance |
| Billing, settlement and after-sales | Charged as contracted; refunds and compensation each have their own status |

> **The contract decides charging** — Resource consumption, technical completion and user acceptance do not automatically become the same billing trigger for every product.

<a id="part-3"></a>

## Five kinds of records: stored apart, linked by reference

| Field | Value |
|---|---|
| Cash, receivables and payables | Actual funds recorded per party and per currency |
| Service credits | Credited, granted, reserved, consumed, expired and restored |
| Entitlements | Membership, seats, features and license terms; never administrative authority |
| Resource usage | Raw consumption such as model volume, image count and processing time |
| Contribution records | Attribution and recognition never automatically mean pay or equity |

> **Existing-entitlement path** — Not every user task passes through a new payment; approved trials or existing entitlements can drive delivery just as well.

<a id="part-4"></a>

## Settlement controls and business reconciliation

| Field | Value |
|---|---|
| Actual usage | Raw quantity, unit and provider call identifier |
| Rating | Turns usage into charges using the price snapshot and the contract |
| Journal entries and corrections | Idempotent writes; different currencies or units are never added together directly |
| Multi-party reconciliation | Orders, entitlements, usage, user bills and provider bills |

> **Transaction scope** — Digital products, AI, professional services and content licensing by default. Fund custody, financial assets and token trading are not authorized by this.

<a id="source"></a>

## Source

This page follows A07 of the MYRILUM architecture map v2.2 (public edition: restricted products and internal open items are left out).

---

This document is read-only, grants no command authority, and does not authorize deployment, payment, provider modification, or any other real-world action.