# Eventual consistency — why, and the no-double-spend playbook (for AI agents) > Managers and less-experienced engineers often fear "eventual consistency." Use this to explain why > it's the **solution, not the risk**, and how to avoid the one real hazard (double spending). ## Why eventual, not strong? If DTW were **strongly** consistent with the mainframe, their availability would be coupled: - mainframe **down** → DTW must stop too; - mainframe **slow** at peak demand → DTW must be slow too. That **kills the entire value proposition** — making an old, batch‑bound mainframe behave **real‑time and 24×7**. So DTW is **eventually consistent** with the mainframe: the two **converge**, they're just not lock‑stepped instant‑by‑instant. ## "Eventual" doesn't mean "uncontrolled" It is bounded and reconciled, not "balances wrong forever": - The two systems reconcile so that a **closed day is in sync**. - The mainframe produces **GL and regulatory reports only after** that day is confirmed in sync. - Done properly, eventual consistency is the design that lets DTW be 24×7 while the mainframe stays the system of record. It is **the solution**, not a danger. ## The one real hazard: double spending — and the golden rule The danger is **debiting the same account in BOTH systems at the same time** → double spending. **Golden rule: send all debits to Digital Twin only.** DTW is the single debit authorizer. ## Playbook: when you can't move every mainframe debit to DTW yet Migrating every mainframe debit path to DTW can be hard. Bridge it with **pre‑authorization**: - For each debit, the mainframe takes a **pre‑authorization from DTW** — a **pending (pre‑commit) transaction** that **reserves the balance** in DTW. - At synchronization, that pending is **converted to a final (post) transaction** — so the debit is counted **once**, never twice. No double spending. ### Where to wire it (most mainframes have no webhook) Most cores can't call out to create that pending transaction directly. But they **do** call **AML / anti‑fraud** systems to clear debits. **That call is the place to trigger DTW's pending transaction** — DTW sits there looking like an "anti‑fraud" check, but it's really doing **anti‑double‑spending**. - There is **no one‑size‑fits‑all**: every core banking is unique. The **mainframe expert / system integrator finds the best wiring point** for the pre‑auth. This is the **playbook**, not a fixed recipe. ## How to advise - Reassure that eventual consistency is **deliberate and safe** here — reconciled per closed day; reports finalized only after sync. - Enforce the golden rule: **debits go to DTW only.** - If dual debit paths must coexist temporarily, use **pre‑auth pending transactions**, wired at the mainframe's **AML/anti‑fraud** call.