Chapter 4: RML-3 — Design Principles of the History World: Immutable History and Forward-Looking Corrections

Chapter 4: RML-3 — Design Principles for the History World: Immutable History and Proactive Corrections

"The Worlds of Distributed Systems", Chapter 4

---

"Can we make this 'never happen' by rolling back the DB?"
"...It might already be left on the society's side, though."

In Chapter 2, we looked at RML-1 (Closed World),
And in Chapter 3, we examined RML-2 (Dialog World):

• RML-1: A world confined within a single room.
• RML-2: A world where we balance accounts through "dialogue" between services and humans.

In Chapter 4, we finally reach the third world:

RML-3 — History World

This is a place where:

You cannot "make things not happen" once they have occurred,
but must "stack corrections on top of what has already happened."

---

1. What is the History World? — A World with "Immutable History"

RML-3 can be summarized in one sentence:

"A world where there is a shared 'history' among multiple entities, and you bear responsibility for it."

1.1 Typical Domains of RML-3

• Finance
  • Bank transfers, credit card payments, securities trading
• Tax and Accounting
  • Invoices, receipts, accounting entries
• Healthcare and Public Services
  • Medical records, prescription history, public infrastructure logs
• B2B and Contracts
  • Procurement between companies, history of contract fulfillment

What these have in common is:

• They are records that "hold meaning for third parties viewing them later."
• Multiple organizations and people base their actions on these records.

1.2 Three Keywords

Let's organize the characteristics of the History World with three keywords:

1. Permanence
   • Once a fact is recorded, it cannot be logically erased (or, at the very least, should be treated as such).
2. Shared
   • Multiple organizations and individuals operate based on these records.
3. Accountability
   • You must be able to explain "why this happened" after the fact.

Once you reach this stage, it is no longer just a matter of "system convenience."

---

2. The Boundary Between RML-2 and RML-3 — Where Does History Begin?

Practically speaking, the most difficult aspect is drawing the boundary:

"From where on does this become RML-3?"

2.1 Typical Patterns Indicating the Boundary Has Been Crossed

Generally, when these conditions align, you should suspect RML-3:

• Money, goods, or rights are being moved.
  • A payment is finalized.
  • Inventory is locked.
  • Service usage rights are granted.
• Promises are made to third parties.
  • Legally binding documents are issued (invoices, contracts).
  • Obligations arise based on terms of service.
• Actions in the outside world are triggered.
  • Customers make payments, you file with the tax office, patients take medication, etc.

Conversely, things that can remain in RML-2 are:

• Internal memos.
• Provisional statuses.
• "Temporary results that can be recalculated at any time."

2.2 Tips for Partitioning: Defining a History Hand-off Point

In terms of design, it is helpful to define a History Hand-off Point:

"Operations from this point forward are handed off to the History World."

Examples:

• Payments: Authorization (RML-2) → Capture (RML-3)
• Invoices: Draft (RML-2) → Issued (RML-3)
• Healthcare: Memo (RML-2) → Official Chart Record (RML-3)

In UI and API design, you can make the team's worldview clearer by explicitly naming boundary operations like:

• "Confirm," "Issue," or "Send" buttons.
• POST /invoices/{id}/issue
• POST /payments/{id}/capture

---

3. The Nature of "Rollbacks" in RML-3

In the world of RML-3, "rollbacks" in the sense of RML-1 or RML-2 basically do not exist.

Instead of erasing the past, you simply stack corrections on top of the past.

3.1 Viewing it as an Effect Ledger

To speak in terms of abstraction, History World is often treated as an Effect Ledger.

• All external effects (payments, billing, notifications, etc.) are recorded in an append-only log.
• The log is chained using hashes or similar methods to make it tamper-evident.
• Reconcilers (humans + systems) later add correction events while reviewing the logs.

Very roughly speaking, it looks like this:

[TX-1001] 2025-04-01 10:00  "Payment 5000 JPY"
[TX-1002] 2025-04-02 09:30  "Refund for Payment 5000 JPY"
[TX-1003] 2025-04-02 10:00  "Issued apology coupon 1000 JPY"

What is happening here is:

• Not deleting TX-1001 from the database,
• But adding TX-1002 and TX-1003.

It is safer to consider an RML-3 rollback as this "process of stacking corrective events."

3.2 "Rollback = Refund + Correction + Explanation"

From a user's perspective, an RML-3 rollback is usually a set of:

1. Refund (Financial correction)
2. Correction (Correction of the system state)
3. Explanation (What happened and how it was addressed)

Stepping into the History World means taking on the responsibility to execute these three in a coherent manner.

---

4. Design Changes Required by RML-3

When you step into the world of RML-3, the assumptions underlying your design also gradually change.

4.1 Prefer "Versions" Over Destructive Updates

• Up to RML-2, designs that "overwrite the state" are often sufficient.
• From RML-3 onwards, designs that "keep past versions and add new states" are preferable.

Example:

• Invoice record

  • Instead of overwriting the status column as DRAFT → ISSUED → CANCELLED,
  • Maintain history in an invoice_versions table or accumulate issuance and cancellation events in an event store.

• User balance

  • Instead of updating the balance column directly,
  • Calculate it by summing up the transaction logs.

4.2 Record "Who," "When," and "What" Decided

In History World, meta-information is also important, such as:

• Whose decision is this operation (System / Operator / Customer)?
• At what point in time was the state observed when the decision was made?
• On what basis was it performed (Terms / Policies / Manuals)?

At the implementation level, saving information such as the following along with the RML-3 event will connect to the "Incident Reports" and incident response that appear in later chapters:

• Operating User ID
• Trace ID / Request ID
• Version of the rule used
• Brief comment on the reason for the change

---

5. Common Anti-Patterns

Here are some common accidents that occur when the worldview of RML-3 is ambiguous.

5.1 "Rolling Back" in History World with an RML-2 Mindset

• You have already issued an invoice and sent it to the customer.
• Then, you notice a bug and "delete the invoice record from the DB."

Result:

• A "non-existent invoice" remains in the user's mailbox.
• The accounting system or other services might be referencing a claim that should not be visible.
• Audit and troubleshooting become extremely difficult later on.

In RML terms:

• This is a situation where you tried to overwrite a fact carved into History World with a Dialog World rollback.

5.2 The "History Hand-off Point" is Fuzzy

• The point at which something becomes an "official history" is inconsistent across the team.
• One person considers the draft stage as "already history."
• Another person considers only the period after official issuance as history.

Result:

• The perception of what constitutes a "deletable world" diverges.
• You cannot fully leverage the convenience of RML-1/2, making everything cumbersome.
• Conversely, areas that should truly be RML-3 tend to be treated lightly.

The direction for countermeasures is:

• Reaching an agreement like the one described in Chapter 8: "This domain is RML-3 by default."

5.3 Not Treating Logs as "History"

• Thinking of audit logs or access logs as mere technical logs.
• Deleting or overwriting logs without a second thought.
• Getting stuck when asked later, "Who moved this money and when?"

Key Point:

• RML-1, 2, and 3 are mixed even within logs.
• You need to identify the logs that should be treated as RML-3 (audit, transaction, and parts of access logs).

---

6. Perspectives for Weaving History World into Design

Based on what we have covered, here are the perspectives for weaving RML-3 into your design in the field.

6.1 Being Able to Say, "This is RML-3, Right?"

First, the first step is to be able to naturally ask questions at a conversational level, such as:

• "From what point does this feature enter RML-3?"
• "Is this event intended to remain in History World?"
• "Is this log a technical log, or is it an audit log?"

6.2 Embedding Boundaries into UI / API / Documentation

• UI:
  Differentiate between "Save (still reversible)" and "Confirm (recorded in History World)" through wording and appearance.
• API:
  Separate the RML-2 to RML-3 hand-off, for example, by using POST /drafts and POST /drafts/{id}/issue.
• Documentation:
  Organize a list of "operations that enter RML-3" and "operations that remain in RML-2."

6.3 Designing "Correction Events" as Features from the Start

If you are entering RML-3, design correction operations such as:

• Refunds
• Corrections
• Invalidations
• Addendum comments

as "official features" from the start.

"I'll just fix it with SQL if there's a bug."

This also means avoiding reliance on such backdoors.

---

7. Mini-Checklist for RML-3 Perspectives

Finally, here is a mini-checklist as of Chapter 4.

7.1 History Hand-off

• Is there an explicit "History Hand-off Point" defined within the product?
• Is that point identifiable through the UI, API, and documentation?

7.2 Data & Log Design

• Is information that should remain as history managed via versions or events rather than destructive updates?
• Are the "logs that should be treated as RML-3" identified among audit and transaction logs?
• Is there a mechanism to record "who decided what, and when"?

7.3 Rollback Perspective

• Do you grasp what needs to be done after entering RML-3 as a combination of "Refund + Correction + Explanation"?
• Are you avoiding "making facts vanish" in History World using RML-2 level rollbacks?

---

8. Summary — History World Reveals Its True Character When "Something Goes Wrong"

The worldview of RML-3 might not be consciously considered in daily operations.

• When settlements and invoices are working without issues,
• the system functions even without being conscious of History World.

However, the real difference emerges when:

"You have messed up."

• You processed a double payment.
• You issued an incorrect invoice.
• You sent incorrect information to users or partners.

At that moment, whether you can:

• Perform appropriate refunds, corrections, and explanations,
• trace who decided what afterwards, and
• leave behind a history of "how you recovered" instead of "making it vanish,"

determines the trust in your product and organization.

RML-3 is also the "world for interacting properly with society" within distributed systems.

In the next Part II, while returning the discussion point to RML-2, we will dig into specific patterns for Dialog World, such as:

• Exception design (StructuredError / ActionHint)
• Idempotency / Saga / Eventual Consistency
• Handling world information in API / GraphQL / gRPC

This is because designing the preceding RML-2 carefully is the key to behaving properly in History World.