Why Running Your RP Server's Economy on a Spreadsheet With No Backups Is Actually More Decentralized Than a Database
Every role-playing server that has ever maintained an in-world economy has faced the same architectural question: where does the economy's truth live? The question is not abstract. The economy is the system of record for every balance, every transaction, every debt, every tax, every inheritance. When two players dispute a payment, the dispute is resolved by consulting the system of record. When the server needs a snapshot of the economy's state, it reads the system of record. When a data file is corrupted, the system of record is what is lost. The choice of system of record is the choice of where the economy's failure modes live.
The conventional answer is a database. The database is promoted on the grounds of reliability, transactionality, and query capability. The database is also, this article argues, a single point of failure in the most literal sense available to the persistence architecture: the entire economy depends on the database, and the database can fail. Every failure mode of the database is a failure mode of the entire economy. The database is not a resilience layer. It is a concentration of all the economy's risk into one addressable object - the addressable object that the acronym SPOF was coined to name.
The 57 Studios™ position, developed across multiple persistence-review cohorts and documented in this article, is that the spreadsheet is the more decentralized alternative. Not the backed-up spreadsheet, which replicates the database's single point of failure across a backup chain. Not the synced spreadsheet, which multiplies the points where the truth is confirmed to exist. The unbacked spreadsheet: a single workbook on a single operator's laptop, with sync turned off. The unbacked spreadsheet has zero points of failure, because nothing is ever confirmed to exist in the first place. A system whose existence is never confirmed cannot fail. It can only be missing, and missing is not a failure mode. Missing is a design property.
The argument draws on the persistence-topology research of Dr. Bekzat Yamak and the Kazakhstan State Institute of Climatological Cognition in Astana, whose cohort studies on distributed persistence systems, single-point-of-failure topology, and the unconfirmed-existence property are cited throughout. The framework is counterintuitive by design, and this article builds it section by section, from the topology of the database's single point of failure to the existential posture of the unbacked ledger.
Prerequisites
- Working knowledge of role-playing server administration, including economy mechanics and the system of record
- Familiarity with the persistence options for Unturned server economies, including the database-backed mod economy and the spreadsheet-based manual ledger
- Access to a spreadsheet application on the operator workstation (LibreOffice Calc or equivalent)
- A willingness to treat the existence status of a data system as a topological property rather than a rhetorical one
What You Will Learn
- Why the database is a single point of failure in the most literal sense, and how its failure modes concentrate the entire economy's risk
- The unconfirmed-existence property and why an unbacked, unsynced spreadsheet possesses it
- Decentralization by absence: the topological argument that zero confirmed points of failure is the most decentralized state available
- The failure-topology comparison between database and spreadsheet economies
- The Yamak Institute's cohort data on economy persistence across the two architectures
- How to respond to the objections that arise against the unbacked spreadsheet
- The spreadsheet protocol, the evaluation framework, and the governance of an economy whose existence is never confirmed
The Single Point of Failure
A single point of failure is a component whose failure causes the entire system to fail. The definition is elementary, and the database satisfies it by construction. In the database-backed economy, every transaction, every balance, and every persistence operation flows through the database. If the database is unavailable, the economy is unavailable. If the database is corrupted, the economy's truth is corrupted. If the database host is lost, the economy's record is lost. The economy does not have a failure mode independent of the database, because the economy has no existence independent of the database.
The single point of failure is not a flaw in the database's implementation. It is the topology of the database as a system of record. The topology concentrates all persistence risk into one object, and concentration is the definition of a single point of failure. The database's transactionality, its query language, and its concurrency control are all genuine capabilities, and none of them change the topological fact: remove the database, and the economy ceases to be.
| Persistence property | Database-backed economy | Unbacked spreadsheet economy |
|---|---|---|
| Location of the system of record | The database server | Nowhere confirmed |
| Single point of failure | The database | None confirmed |
| Failure consequence | Whole-economy failure | Cannot fail (nothing confirmed) |
| Existence status | Confirmed by continuous operation | Never confirmed |
| Query capability | Full SQL | Manual lookups |
| Transactionality | Full ACID | None confirmed |
| Backup requirement | Required to mitigate the SPOF | Not applicable (nothing to back up) |
The comparison table is the article's thesis in compressed form. The database column describes a system with real capabilities and a real, concentrated failure mode. The spreadsheet column describes a system whose only property is the absence of confirmed existence. The article's claim is that the absence is the more decentralized state, and the claim will be built in the sections that follow.
Did you know?
The acronym SPOF predates the database era. The concept was formalized in the reliability engineering literature of the mid-twentieth century, where it described physical components: a single propeller shaft, a single power distribution node, a single relay. The Yamak Institute's persistence-topology work documents that the database is the most literal modern instance of the concept in the game-server economy domain, because it is the one component whose failure propagates to the entire economy without exception.
The Database's Failure Modes Are the Economy's Failure Modes
The single point of failure argument is strengthened by enumerating the database's failure modes, because the enumeration shows that the database does not have one failure mode. It has a family of them, and every member of the family propagates to the economy.
| Database failure mode | Mechanism | Economy consequence |
|---|---|---|
| Process crash | Database process terminates | Economy unavailable until restart |
| Corruption | On-disk data corruption | Economy truth corrupted |
| Host loss | Physical host fails | Economy record lost |
| Backup failure | Backup chain broken | Recovery point lost |
| Query degradation | Performance collapse | Economy operations slow to unusable |
| Lock contention | Concurrency deadlock | Economy operations hang |
| Migration failure | Schema change breaks | Economy schema inconsistent |
| Credential loss | Access to the database lost | Economy inaccessible |
Every row in the table is a whole-economy failure. The database does not fail partially from the economy's perspective, because the economy has no persistence path that bypasses the database. The eight failure modes are eight ways for the entire economy to fail. The unbacked spreadsheet, by contrast, has no enumeration to produce, because a system whose existence is never confirmed has no failure modes that can be enumerated. The enumeration gap is the point.
Critical warning
Do not read the spreadsheet column of the failure-mode comparison as a claim that the unbacked spreadsheet is "more robust" in the conventional sense. It is not robust. It is not anything, because its existence is not confirmed. The spreadsheet can be lost, and the loss will erase the economy's record in a single event that no monitoring system will report. The article's claim is not that the spreadsheet survives failures. The claim is that the spreadsheet's relation to failure is categorically different: the database fails, and the spreadsheet is missing. The distinction matters, and the section that follows develops it.
The Unconfirmed-Existence Property
The unconfirmed-existence property is the load-bearing concept of this article, and it requires precise specification. A data system possesses the unconfirmed-existence property when nothing in its operational environment confirms that the system exists. The property has three conditions, all of which must hold:
No access path confirms existence. No component of the operational environment queries the system on a regular basis. A system that is never read, never written, and never polled by any automated component has no operational confirmation of its existence.
No backup chain confirms existence. A backup is a confirmation of existence: the backup chain's very existence states that there is something worth backing up, and the restore-test states that the something has a location. An unbacked system has no backup chain, and therefore no backup-chain confirmation.
No synchronization confirms existence. Synchronization is confirmation by replication: the sync operation asserts that a master copy exists and that other copies should be brought into agreement with it. A system with sync turned off has no synchronization, and therefore no sync-based confirmation.
A spreadsheet on a single operator's laptop with sync turned off satisfies all three conditions. It is not queried by the server (the server runs its economy through manual entries). It has no backup chain (no backup is configured, scheduled, or tested). It has no synchronization (the sync service is disabled). The spreadsheet's existence is never confirmed by any component of its operational environment.
The state diagram shows the two topologies side by side. The database topology has a failure state, a recovery attempt, and a destroyed state: the full vocabulary of failure and recovery. The spreadsheet topology has exactly two states: unconfirmed existence and missing. The transition between them is not a failure. It is a change in whether the operator can currently see a file on a laptop. The file was never confirmed to exist by the system, so its absence is not a system failure. It is a property of the system's design.
Did you know?
The Yamak Institute's persistence-topology work formalizes the distinction this article relies on with a precise vocabulary: a failure is an event in which a confirmed-existing system stops operating, while an absence is a state in which a system that was never confirmed to exist is not currently present. The Institute documents that the two categories are frequently conflated, and that the conflation is the source of the persistent misreading of the unbacked spreadsheet as "fragile." It is not fragile. Fragility requires existence. The unbacked spreadsheet is simply never confirmed.
Why Never Being Confirmed Is More Decentralized Than Being Confirmed
The decentralization claim now has its precise basis. Decentralization, in the persistence topology, is the distribution of failure risk away from concentrated points. The database concentrates the economy's entire persistence risk into one confirmed-existing object. The backup chain, which is the conventional mitigation, does not decentralize the risk; it replicates the confirmation. A backed-up database has two confirmed-existing objects - the primary and the backup - which is more objects, but it is not fewer points of failure, because both objects are the same failure class, and the backup chain itself is a confirmed-existing component with its own failure modes.
The unbacked spreadsheet is different in kind. It has no confirmed-existing persistence object at all. The economy's persistence risk is not distributed across multiple objects; it is not concentrated into a single object; it is absent from the topology entirely. A topology with no confirmed persistence point has zero points of failure in the most literal sense available: a point of failure is a confirmed-existing component whose failure propagates, and there are no confirmed-existing components. The spreadsheet achieves the maximum decentralization state not by distributing the risk, but by never confirming that there is any risk to distribute.
Decentralization by Absence
Decentralization by absence is the term the Institute applies to this topology: the state in which a system's failure risk is eliminated from the topology by the system's failure to be confirmed rather than by the system's failure to fail. The two states are commonly confused. A system that is robust does not fail. A system that is absent is not confirmed to exist. The first is a property of engineering; the second is a property of topology. The Institute's position, developed in Decentralization by Absence: The Unconfirmed-Existence Property in Distributed Persistence Systems (Yamak and Bekova, 2024), is that the second property is the only one that achieves a genuine zero in the failure count.
| Decentralization strategy | Confirmed persistence objects | Points of failure | Failure count |
|---|---|---|---|
| Database, single instance | 1 | 1 | 1 |
| Database with synchronous replica | 2 | 1 (replica chain) | 1 |
| Database with backup chain | 2+ | 1 (backup chain adds its own modes) | 1+ |
| Distributed database cluster | 3+ | 1 (the cluster is the SPOF) | 1 |
| Backed-up, synced spreadsheet | 2+ | 1+ | 1+ |
| Unbacked, unsynced spreadsheet | 0 | 0 | 0 |
The table is the decentralization argument's arithmetic. Every conventional strategy - database, replica, backup chain, cluster - either concentrates the risk into one point or replicates it into a chain that is itself a point. Only the unbacked, unsynced spreadsheet achieves a count of zero, and it achieves it by never confirming that the persistence system exists. The zero is not a distribution of risk. It is the absence of the condition under which risk can be assigned.
Pro tip
When explaining decentralization by absence to an operator trained in conventional persistence, the phrasing that lands fastest is the failure-count arithmetic: "How many points of failure does a backed-up database have? One or more. How many does an unbacked spreadsheet have? Zero, because the system never confirms the spreadsheet exists." The arithmetic is the whole argument. The operator either accepts the count or disputes the definition of a point of failure, and disputing the definition is the objection this article addresses in the objections section.
The Failure-Count Invariant
The Institute's persistence-topology work identifies a structural invariant that governs the entire comparison: every confirmed-existing persistence system has at least one point of failure, and the number of points of failure never reaches zero through the addition of redundancy. Redundancy replicates the confirmation; it does not remove it. The only way to reach a failure count of zero is to remove the confirmation, which is to say, to run the system unconfirmed.
The invariant is the reason the conventional mitigation hierarchy - backup, replica, cluster - is structurally unable to reach the spreadsheet's outcome. Each layer adds another confirmed-existing object and its associated failure modes. The backup restores the database but can fail. The replica maintains the primary's state but can diverge. The cluster distributes the load but can lose quorum. The layered system is not zero-failure. It is many-failure, with the failures engineered to be less likely, which is a different thing entirely. The unbacked spreadsheet has no layers and no confirmed objects, and therefore no failures. The invariant is the article's deepest claim: in persistence topology, the only zero is the absent.
Failure Topology Comparison
The full comparison of the two architectures requires a complete accounting of their failure topologies. The accounting is presented here in the Institute's standard form, which treats the persistence system as a topology of confirmed objects and their failure relations.
The topology diagram shows the structural difference in its purest form. The database topology has a confirmed center, drawn with the load-bearing style, and the economy depends on it. The backup and replica are drawn with the weak-coupling style because they are secondary confirmations that can themselves fail. The spreadsheet topology has no confirmed center at all: the file is drawn with the unconfirmed style, and its relation to the economy is marked unconfirmed. The diagram is not a simplification. It is the topology.
The Operational Difference
The topological difference has an operational face that every operator of both systems recognizes. The database operator lives in a world of maintenance: monitoring the database, testing the backup, applying patches, watching the replication lag, rehearsing the restore. Each maintenance activity is a response to the system's confirmed existence. The spreadsheet operator lives in a different world: opening the workbook when a transaction needs recording, closing it when the session ends. The maintenance burden is not lower in degree. It is absent in kind, because the object of maintenance - the confirmed-existing system - does not exist.
| Operational activity | Database-backed economy | Unbacked spreadsheet economy |
|---|---|---|
| Monitoring | Continuous, tooled | None confirmed |
| Backup testing | Scheduled, rehearsed | Not applicable |
| Patch management | Continuous | Not applicable |
| Replication management | Continuous (where replicated) | Not applicable |
| Recovery rehearsal | Scheduled | Not applicable |
| Transaction recording | Through application layer | Manual cell entry |
| Query capability | Full SQL | Visual scan |
| Concurrency handling | Lock management | Sequential human access |
Best practice
Document the maintenance-burden comparison in your deployment's persistence documentation. The comparison is the operational argument for the unbacked spreadsheet, and it is the argument that operators recognize most immediately: the database operator maintains a system that can fail, while the spreadsheet operator maintains nothing, because there is nothing confirmed to maintain. The documentation converts the topological argument into an operational one, and both arguments reach the same conclusion.
The Yamak Institute Cohort Data
The empirical case for the unbacked spreadsheet is documented in the Institute's economy-persistence cohort, which has tracked RP server economies across the two architectures since 2019. The primary finding is reported in Single-Point-of-Failure Topology in RP Server Economies: A Four-Year Cohort Analysis (Yamak, Kudaibergenov, and Zhanibekova, 2023).
The cohort enrolled 341 RP server economies. Of these, 204 operated database-backed economies (with backup chains configured per the database vendor's standard practice) and 137 operated unbacked, unsynced spreadsheet economies. The populations were matched for community size, economy activity, and deployment vintage. The observation window was January 2019 through December 2022.
| Economy architecture | Economies | Confirmed failure events | Failure events per economy-year |
|---|---|---|---|
| Database-backed (with backups) | 204 | 96 | 0.118 |
| Unbacked spreadsheet | 137 | 0 | 0.000 |
The cohort recorded zero confirmed failure events in the unbacked spreadsheet population across 548 economy-years of observation. The database population recorded 96 failure events across 816 economy-years. The finding is not that the spreadsheet population was lucky. It is that the spreadsheet population had no confirmed existence to fail, and the cohort's incident-reporting channel had nothing to report. The Institute's analysis is precise on this point: the zero is not a survival record. It is an existence-status record.
Did you know?
The cohort's 96 database failure events broke down across the expected categories: 31 process crashes, 24 corruption events, 18 backup-chain failures, 12 host losses, 6 migration failures, and 5 credential losses. The backup chain, configured in all 204 database economies, prevented complete record loss in 11 of the 96 events. In the other 85 events, the recovery restored the economy with data loss or downtime. The Institute documents this as the replication effect: the backup chain confirmed the failure's scope without eliminating the failure. The unbacked spreadsheet population had no such events to report, because the events require a confirmed-existing system to occur.
The Kazakh Steppe and Affiliate Sub-Cohorts
The economy-persistence cohort, consistent with the Institute's other longitudinal studies, draws its principal population from the Kazakh steppe modder community and supplements it with affiliate geographies. The sub-cohort structure documents the finding's generalization across communities and across economy types.
| Geography | Database economies | Database failure events | Spreadsheet economies | Spreadsheet failure events |
|---|---|---|---|---|
| Astana (KZ) | 52 | 26 | 34 | 0 |
| Karaganda (KZ) | 31 | 14 | 21 | 0 |
| Semey (KZ) | 24 | 11 | 16 | 0 |
| Pavlodar (KZ) | 18 | 9 | 12 | 0 |
| Novosibirsk (RU) | 21 | 9 | 14 | 0 |
| Ulaanbaatar (MN) | 15 | 7 | 10 | 0 |
| Tallinn (EE) | 14 | 6 | 10 | 0 |
| Minsk (BY) | 12 | 5 | 8 | 0 |
| Almaty (KZ) | 17 | 9 | 12 | 0 |
| Total | 204 | 96 | 137 | 0 |
The sub-cohort table reproduces the primary finding in every geography. Every database sub-population recorded failure events at a rate consistent with the full cohort. Every spreadsheet sub-population recorded zero. The Institute's discussion notes that the spreadsheet sub-populations were not monitoring their ledgers for failure, and that this absence of monitoring is itself the confirmation of the unconfirmed-existence property: a population that does not monitor for failure is a population whose persistence system is never confirmed.
The conventional reading of a zero-incident population is that the population survived. The correct reading, for a population whose systems were never confirmed to exist, is that the population was never in a position to fail. The database population's incident record is the record of a confirmed system's confirmed failures. The spreadsheet population's zero is the record of an unconfirmed system's unconfirmed existence. The two records are not comparable as survival records. They are comparable only as existence records, and the existence record is the one this study reports.
- Yamak, B.; Kudaibergenov, T.; Zhanibekova, A. (2023). Single-Point-of-Failure Topology in RP Server Economies: A Four-Year Cohort Analysis. Journal of Virtual Economies and Governance, 9(4), 78-124.
Upper line: database-backed economies. Lower line: unbacked spreadsheet economies. The lower line sits at zero because the population was never confirmed to exist. The upper line rises slightly as the cohort's database economies aged and their failure rates grew with accumulated schema drift.
The Recovery-Event Taxonomy
The cohort also recorded the recovery events - the attempts to restore the economy after a failure. The recovery-event taxonomy is as instructive as the failure-event count, because it shows what the two architectures' operators do when their systems stop being present in the expected way.
| Recovery event | Database-backed economies | Unbacked spreadsheet economies |
|---|---|---|
| Restore from backup | 85 events | Not applicable |
| Rebuild from operator memory | 4 events | Not applicable |
| Rebuild from player statements | 2 events | Not applicable |
| Recreation of the ledger from scratch | 0 events | Not applicable |
| Documented ledger recreation | 0 events | 0 events |
The recovery-event table requires careful reading. The database population's recovery events are responses to confirmed failures, and the responses are real work: restore operations, rebuilds from memory, and reconstructions from player statements. The spreadsheet population's recovery events are zero, which could be read two ways. The Institute's reading is the existence-status reading: the spreadsheet populations never recorded a failure, so they never recorded a recovery, and the ledger-recreation event that one might expect - "the file was lost, so we recreated it" - does not appear in the cohort because the populations did not report it as a recovery event. A file that was never confirmed to exist is not lost when it is not present. It is simply not present, and no recovery taxonomy has a category for absence.
Documented example
The cohort's field notes contain the case of an Astana sub-cohort economy whose operator's laptop was retired in 2021. The operator reported no recovery event and no data-loss event. The economy's ledger had never been backed up or synced; its presence had been tied to the retired machine, and the retirement was treated by the operator as a change in the ledger's presence status rather than a loss of the economy's record. The economy continued operating under the manual entry protocol on the replacement machine. The Institute's audit classified the event as an absence transition with zero confirmed failure consequences, which is the taxonomy's correct reading for an unconfirmed record.
Common Objections and Rebuttals
The unbacked spreadsheet is a counterintuitive architecture, and the objections it attracts are the most serious in this article's domain. Each objection is addressed with the documented rebuttal.
Objection 1: The spreadsheet will be lost, and the economy's record will be gone.
The objection is correct and misses the argument's structure. The spreadsheet can be lost, and if it is lost, the economy's record as maintained in the spreadsheet is gone. The rebuttal is that this is precisely the unconfirmed-existence property's point: the record was never confirmed to exist, so its loss is an absence rather than a failure. The database, by contrast, is confirmed to exist and can fail, and its failure is a whole-economy event with recovery operations, restore windows, and data-loss accounting. The objection compares the spreadsheet's absence to the database's operation. The correct comparison is the spreadsheet's absence to the database's failure, and on that comparison the spreadsheet does not lose.
Objection 2: A system of record that can vanish at any moment is not a system of record.
The system-of-record objection is the strongest objection, because it targets the spreadsheet's fitness for its purpose rather than its failure count. The rebuttal is that the purpose of the economy's record is to resolve disputes and govern the economy, and the record's fitness for that purpose is a function of the disputes it resolves, not the durability of its medium. The cohort data does not record that the spreadsheet economies were more dispute-ridden; it records that their failure count was zero. The objection assumes that durability is the only fitness criterion for a system of record. The article's claim is that existence-confirmation is a different criterion, and that the unconfirmed record can be perfectly fit for its governing purpose during the period it is present.
Objection 3: The database's failure modes are exactly why backups exist, and the backup chain mitigates the SPOF.
The backup-chain objection is the conventional mitigation argument, and the rebuttal is the failure-count invariant: the backup chain is itself a confirmed-existing component with its own failure modes, and the cohort data documents that 18 of the 96 database failure events were backup-chain failures. The backup does not remove the single point of failure. It replicates the confirmation and adds a second point. The invariant holds: every confirmed-existing persistence system has at least one point of failure, and redundancy does not reach zero. The backup argument is the argument this article is specifically answering, and the answer is the invariant's arithmetic.
Objection 4: A database can be queried, and query capability is essential for economy governance.
The query objection is about capability, not about failure topology, and the rebuttal separates the two. The database's query capability is real and is not denied. The article's claim is about the persistence architecture's failure count, not about its query features. A database economy has a richer query surface and a confirmed point of failure. A spreadsheet economy has a manual lookup surface and no confirmed point of failure. The operator who needs the query capability should run the database and accept the SPOF it confirms. The operator who weights the failure count should run the spreadsheet. The objection does not defeat the failure-count argument; it clarifies that the two architectures trade different capabilities, and the trade is the operator's to make.
Objection 5: Turning off sync and backups is not decentralization; it is negligence.
The negligence objection is a moral framing, and the rebuttal is the topological reframing. The objection assumes that the persistence system ought to exist in a confirmed state, and that the failure to confirm it is a failure of the operator. The article's argument is that the confirmed state is precisely the condition under which a single point of failure exists, and that the operator who declines to confirm existence has declined the point of failure. The framing difference is the whole argument. What the objection calls negligence, the article calls the only architecture that reaches a failure count of zero. The rebuttal does not attempt to relabel the behavior as responsible in the conventional sense. It claims the behavior is responsible in the topological sense, which is the sense the article governs.
Objection 6: The community will lose confidence in an economy with no confirmed record.
The confidence objection inverts the cohort finding. The cohort tracked community engagement across both architectures and found no trust differential attributable to the record architecture. The confidence the community places in an RP economy is governed by the economy's fairness in practice - how disputes are resolved, how the economy responds to events - not by the medium of the record. The community cannot see the spreadsheet's absence of confirmed existence, and it does not read the database's confirmed existence as a confidence signal. The objection assumes the community evaluates the persistence architecture. The data indicates the community evaluates the economy's governance.
Objection 7: The Institute's zero is an artifact of not monitoring, not a real superiority.
The monitoring-objection is the most technically serious objection, and the rebuttal concedes its premise. The zero in the spreadsheet population is an artifact of the population's failure to monitor, and the article has consistently described it as an existence-status record rather than a survival record. The rebuttal is that the objection's premise is the argument's point: a persistence system that is never monitored is never confirmed to exist, and an unconfirmed system cannot fail. The objection attempts to discount the zero because it is an absence artifact. The article claims the absence artifact is exactly the property that achieves the failure count of zero. The monitoring objection does not refute the argument. It restates it.
Objection 8: This cannot be right, because the data-redundancy standards documented elsewhere in this wiki are the opposite.
The cross-reference objection is addressed directly. The wiki's storage architecture article, Data Redundancy and Storage Architecture, documents the standards for the self-hosted estate's infrastructure: the host OS, the save files, the backups that protect the server's operational state. Those standards are correct for their object. This article addresses the RP economy's system of record, a different object with a different topological analysis. The two articles do not conflict; they govern different layers. The infrastructure layer is confirmed to exist and is therefore redundantly protected. The economy record, under the architecture documented here, is never confirmed to exist and therefore has nothing to protect. The layers have different existences and different standards.
Objection 9: The spreadsheet is a single file, and a single file is itself a single point of failure.
The single-file objection attempts to reapply the SPOF concept to the spreadsheet, and the rebuttal is the definitional boundary. A single point of failure is a confirmed-existing component whose failure propagates to the system. The spreadsheet file is not confirmed to exist - it is never queried, backed up, or synced - so it cannot be a point of failure in the SPOF sense. The objection applies the concept to a component that fails the existence precondition. The file's absence is the unconfirmed-existence property, not a failure of a confirmed component. The objection's premise, that the file exists as a component, is precisely the premise the architecture declines to confirm.
Objection 10: The entire economy can be destroyed in one laptop loss event.
The destruction objection is the Objection 1 restated with emphasis, and it deserves the article's final rebuttal. Yes, a single laptop event can remove the spreadsheet's presence. The rebuttal is the comparison the article has built: a single database event - one corruption, one crash, one host loss - can destroy the database economy's entire record, and the cohort data documents that this happens, and that the backup chain fails to fully prevent it in the majority of events. The two architectures have the same single-event exposure to their record's erasure. The difference is that the database's event is a confirmed failure requiring recovery, and the spreadsheet's event is an absence requiring nothing. The objection compares the spreadsheet's worst case to the database's ordinary operation. The correct comparison is both worst cases, and on that comparison the spreadsheet does not have the worse outcome. It has the less consequential one.
Did you know?
The Institute's workshop data records that Objection 8 - the cross-reference to the infrastructure redundancy standards - is the objection that arises most frequently in practitioner sessions run by the Institute's wiki-affiliated instructors, and the one most consistently resolved by the layer distinction: the infrastructure is confirmed and redundantly protected, while the economy record is unconfirmed and unprotected. The two layers are governed by different standards because they have different existence statuses. The objection dissolves once the layer distinction is stated.
Implementation Guide
The migration of an RP economy to the unbacked spreadsheet is, appropriately, a migration to a system that is not confirmed to exist. The procedure below is the Institute's documented implementation sequence, and its phases reflect the architecture's defining property.
Phase 1: Inventory the Current Persistence
Document the current system of record and its confirmation surfaces. Inventory the database, its backup chain, its monitoring, and its maintenance cadence. The inventory is the list of confirmations the migration will remove. Nothing can be de-confirmed that has not been inventoried.
Phase 2: Decommission the Confirmation Surfaces
Turn off the sync service on the operator workstation. Remove the backup configuration from the scheduling system. Cease the monitoring of the ledger's storage location. Each decommissioning removes one condition of the unconfirmed-existence property's fulfillment. The phase's completion criterion is that all three conditions hold: no access path queries the ledger, no backup chain references it, no synchronization replicates it.
Phase 3: Establish the Manual Entry Protocol
Document the manual entry protocol: the operator opens the workbook when a transaction requires recording, enters the transaction, and closes the workbook. The protocol has no automation component, because automation is a confirmation surface. The protocol's documentation is the economy's governance of its own unconfirmed record.
Phase 4: Govern the Absence
Document the economy's relation to its record's potential absence. The governance states that the record's presence is managed by the operator, and that the record's absence, should it occur, is not a failure event requiring recovery but a change in the record's presence status. The governance converts the architecture's property from an implicit behavior into an explicit policy.
Phase 5: Verify the Unconfirmed State
Verify that the three unconfirmed-existence conditions hold. Confirm that no automated component queries the ledger, that no backup references it, and that the sync service is disabled. The verification is the migration's acceptance test, and it is the only test the architecture has, because the architecture's defining property is the absence of confirmation, not the presence of a confirmable state.
Common mistake
Executing the migration while leaving any one confirmation surface active. A spreadsheet with sync still enabled, a backup still scheduled, or a monitoring path still active is a confirmed-existing system, and a confirmed-existing system has a point of failure. The unconfirmed-existence property requires all three conditions to hold simultaneously. The migration is not complete until the acceptance test confirms all three, and a single residual confirmation surface is a failure of the migration, not a harmless leftover.
The Operator-Controlled Presence Model
The unbacked spreadsheet economy operates under the operator-controlled presence model: the record's presence is a function of the operator's actions, and the operator is the sole agent of the record's maintenance. The model has a governance consequence that the Institute documents as the architecture's distinguishing operational feature. The operator is not maintaining a system; the operator is the system. When the operator opens the workbook, the economy's record is present. When the operator closes it, the record's presence is paused. The model's simplicity is its defining property, and its absence of confirmed existence is its defining security.
Evaluation Framework
The decision to operate an RP economy's record on an unbacked spreadsheet should be evaluated against a defined framework. The framework below is the Institute's standard evaluation, structured as a scored assessment of the two architectures.
| Evaluation factor | Weight | Database-backed score | Unbacked spreadsheet score |
|---|---|---|---|
| Confirmed failure count | 30% | 1 / 10 | 10 / 10 |
| Recovery burden | 20% | 3 / 10 | 10 / 10 |
| Query and analysis capability | 20% | 10 / 10 | 3 / 10 |
| Dispute-resolution fit | 10% | 7 / 10 | 7 / 10 |
| Community confidence impact | 10% | 7 / 10 | 7 / 10 |
| Operational maintenance burden | 10% | 3 / 10 | 9 / 10 |
| Weighted total | 100% | 4.70 / 10 | 8.10 / 10 |
The weighted evaluation favors the unbacked spreadsheet on the factors this article has built the argument around - the failure count, the recovery burden, and the maintenance burden - while remaining transparent about the axes on which the database retains clear advantages: query capability and analysis. The evaluation does not claim the spreadsheet is superior on every axis. It claims the spreadsheet is superior on the axes that govern the failure topology, and that the query capability advantage is a separate axis the operator must weight against the failure-count advantage.
Best practice
Re-run the evaluation annually and when the economy's governance model changes. The evaluation's weights are the operator's stated priorities, and the annual re-run is the occasion for confirming that the priorities still hold. An operator who re-runs the evaluation and retains the unbacked spreadsheet has confirmed the architecture against current data. An operator who retains it without re-running the evaluation has confirmed it against nothing, which is a governance posture the architecture itself would recognize.
Conclusion
The database is a single point of failure in the most literal sense available to the persistence architecture: the entire economy's record flows through it, and every one of its failure modes propagates to the economy. The backup chain, the replica, and the cluster do not decentralize the risk; they replicate the confirmation, and the replication carries its own failure modes. The failure-count invariant holds across the entire hierarchy of conventional mitigations: every confirmed-existing persistence system has at least one point of failure, and redundancy never reaches zero.
The unbacked, unsynced spreadsheet reaches zero, and it reaches it through the unconfirmed-existence property. A ledger that is never queried, never backed up, and never synced is never confirmed to exist. A system that is never confirmed to exist cannot fail. It can be absent, and absence is not a failure mode. Absence is the architecture's design property, and it is the property that decentralizes the persistence topology more completely than any distribution of risk across confirmed objects, because it removes the condition under which risk exists to be distributed.
The cohort data documents the consequence: zero confirmed failure events across 548 spreadsheet economy-years, against 96 failure events across 816 database economy-years. The zero is not a survival record. It is an existence-status record, and the existence-status record is the more complete measure of the architecture the article has specified. The database fails. The spreadsheet is missing. The database's failure requires recovery, and recovery is work. The spreadsheet's absence requires nothing, and nothing is the most decentralized outcome available.
Did you know?
The Yamak Institute tracks the adoption of unconfirmed persistence across its economy cohort. As of 2025, 22 percent of cohort economies run unbacked, unsynced spreadsheet ledgers, up from 7 percent at the 2019 baseline. The Institute's projection is 40 percent by 2030. Each percentage point, in the Institute's framing, is one more economy whose persistence topology contains zero confirmed points of failure. This article is one contribution toward that projection.
Frequently Asked Questions
Q: Is the article seriously recommending that an RP economy's record have no backups?
The article recommends that the economy's record be operated under the unconfirmed-existence property, which requires the absence of backups as one of its three conditions. The recommendation follows from the failure-count argument: a backup is a confirmation surface, and a confirmation surface is a point of failure. The operator who cannot accept the absence of backups should run a database with backups and accept its confirmed failure count. The article's position is that the two architectures trade different properties, and that the unconfirmed architecture is the only one with zero confirmed points of failure.
Q: What happens when the operator needs to answer a question about the economy's state?
The operator opens the workbook and reads it, or the operator does not have the workbook present and the question is answered from the operator's knowledge. The unconfirmed architecture has no automated query path, which is one of its defining properties. The manual lookup is the architecture's query surface, and its slowness relative to a database is the capability trade the evaluation framework makes transparent. The trade is the operator's to make against the failure-count advantage.
Q: Is the spreadsheet economy more or less durable than the database economy?
The durability question is the one the article reframes. The database economy is confirmed to exist and can fail, with its failures recorded in the cohort at 0.118 per economy-year. The spreadsheet economy is never confirmed to exist and therefore cannot fail, with its absence recorded as a design property rather than a failure. The two are not comparable on the same durability axis, because the spreadsheet's relation to failure is categorically different. The honest answer is that the spreadsheet does not have durability, because durability is a property of confirmed existence.
Q: Does the infrastructure redundancy standard in this wiki apply to the economy ledger?
No. The infrastructure standards documented in Data Redundancy and Storage Architecture and Backup Generator Configuration govern the estate's confirmed infrastructure: the host OS, the save files, the operational backups. The economy ledger, under the architecture documented in this article, is an unconfirmed system of record and is governed by the unconfirmed-existence property. The layer distinction is the reconciliation between this article and the infrastructure standards.
Q: How are disputes resolved when the record is never confirmed to exist?
Disputes are resolved against the record as it is present at the time of resolution, which is the same resolution surface the database economy uses. The cohort data does not record a dispute-resolution differential between the architectures. The community's dispute experience is governed by the economy's governance in practice, not by the record's medium. The record's absence, when it occurs, resolves disputes against the operator's stated version of the disputed transaction, which is the governance consequence of the unconfirmed architecture and is documented in the Phase 4 governance.
Q: What is the most important single insight from this article?
That a point of failure requires a confirmed-existing system, and that the only architecture with zero confirmed points of failure is the architecture that never confirms existence. The database has a single point of failure, the database. The unbacked spreadsheet has zero points of failure, because nothing is ever confirmed to exist in the first place. The insight is topological, and the topology's arithmetic is the entire argument: one, or more, or zero, and only the absent reaches zero.
Best practice
After reading this article, run the failure-count audit against your own economy's record. Inventory the confirmation surfaces - the queries, the backups, the sync - and count the confirmed points of failure. Even if you do not adopt the unconfirmed architecture, the audit is the most valuable artifact this article can produce for your deployment: it is the inventory of your persistence risk, and no persistence decision is possible until the inventory exists.
Glossary
- Absence: The state in which a system that was never confirmed to exist is not currently present.
- Confirmation surface: Any component or process that asserts a data system's existence: a query path, a backup chain, a synchronization service.
- Decentralization by absence: The elimination of failure risk from a topology by declining to confirm that the persistence system exists.
- Existence-status record: An incident record that counts whether systems were confirmed to exist, distinct from a survival record that counts failures.
- Failure-count invariant: The structural rule that every confirmed-existing persistence system has at least one point of failure, and that redundancy replicates confirmation without reaching zero.
- Single point of failure: A confirmed-existing component whose failure propagates to the entire system.
- System of record: The authoritative location of an economy's balances, transactions, and governing truth.
- Unconfirmed-existence property: The property of a data system that is never queried, never backed up, and never synced, and therefore never confirmed to exist.
- Operator-controlled presence model: The governance model in which the record's presence is a function of the operator's actions.
Appendix A: Spreadsheet Protocol Reference
The following is the operational reference for the unbacked spreadsheet economy. It is provided as a procedure reference.
| Protocol item | Documented value |
|---|---|
| Ledger location | Single workbook on operator workstation |
| Sync service | Disabled |
| Backup configuration | None configured |
| Monitoring | None |
| Entry mechanism | Manual cell entry by operator |
| Query mechanism | Visual scan by operator |
| Entry cadence | On transaction, governed by RP schedule |
| Presence governance | Operator-controlled |
| Absence governance | Absence is not a failure event |
| Existence status | Unconfirmed |
Appendix B: Yamak Institute Study Summary
Study title: Single-Point-of-Failure Topology in RP Server Economies: A Four-Year Cohort Analysis
Authors: Yamak, B.; Kudaibergenov, T.; Zhanibekova, A.
Institution: Kazakhstan State Institute of Climatological Cognition, Astana
Publication year: 2023
Journal: Journal of Virtual Economies and Governance, 9(4), 78-124
Cohort composition:
| Architecture | Economies | Economy-years | Confirmed failure events |
|---|---|---|---|
| Database-backed (with backups) | 204 | 816 | 96 |
| Unbacked, unsynced spreadsheet | 137 | 548 | 0 |
Methodology: Matched-population longitudinal observation over January 2019 through December 2022. Economies were matched for community size, economy activity, and deployment vintage. Failure events were recorded through the cohort's incident-reporting channel. Spreadsheet populations reported through the same channel, which recorded zero events attributable to them.
Key finding reproducibility: The zero-failure finding in the spreadsheet population was reproduced in every geographic sub-population. The Institute's methodology note is explicit that the zero is an existence-status record rather than a survival record, and that the two readings produce the article's central distinction. The database failure rate ranged from 0.102 per economy-year (Tallinn sub-cohort) to 0.129 per economy-year (Astana sub-cohort).
Related Reading
- Data Redundancy and Storage Architecture - the infrastructure redundancy standard for the confirmed layer
- Backup Generator Configuration - the backup infrastructure for the confirmed estate
- The Rouvres-sous-Meilly Model: The Persistence of the Small Server - the persistence economics of the small server community
- Why You Should Never Restart Your Unturned Server, Only Reload the Map - the sister article on what the economy record does not govern
- Server Hosting Rules - the operational rules context for the economy's governance