How NewTon DC Tournament Manager is built to be virtually crash-proof.
NewTon DC Tournament Manager is built around a single overriding principle: a tournament that has started must never lose data or end up in an invalid state. Every architectural decision follows from that.
This means no dynamic calculations that could produce different results depending on execution order, no mutable shared state that different code paths can corrupt, and no operations that can half-complete. Instead, NewTon DC Tournament Manager uses hardcoded lookup tables as the single source of truth for all bracket logic, and a transaction-based history system that logs every match action and enables surgical undo.
The result is a system that can survive almost any failure — a misclick, a browser crash, a power cut mid-tournament — and be restored to an exact, consistent state.
The most critical architectural decision in NewTon DC Tournament Manager is how bracket progression works. Many systems calculate where a player should go next at runtime — using formulas, round arithmetic, or conditional logic. NewTon DC Tournament Manager does not.
Instead, all bracket progression is defined in a single constant object called MATCH_PROGRESSION, hardcoded in clean-match-progression.js:
const MATCH_PROGRESSION = {
8: { /* all rules for 8-slot brackets */ },
16: { /* all rules for 16-slot brackets */ },
32: { /* all rules for 32-slot brackets */ }
};Every match — on the Frontside and Backside — has an explicit entry that defines exactly where the winner goes and where the loser goes:
'FS-1-1': {
winner: ['FS-2-1', 'player1'],
loser: ['BS-1-1', 'player1']
}There is only one function that moves players between matches — advancePlayer() — and it does nothing but look up the rule and apply it. No calculations. No special cases. No branches.
Every match action in NewTon DC Tournament Manager is recorded as a transaction in a per-tournament log. The tournament's current state is not just a snapshot — it is the sum of every recorded action that has been applied to it.
This approach — known as event sourcing — has two important consequences:
The transaction log is capped at 1,000 entries, visible and manageable via the Developer Console. The Console also shows a Transaction Health indicator so operators can see at a glance how much of the limit is in use.
NewTon DC Tournament Manager maintains strict isolation between three categories of data, each stored independently and never mixed:
| Category | What it contains | Storage key |
|---|---|---|
| Tournament data | Players, matches, bracket, placements, status | tournament_{id} |
| Transaction history | Full audit log of every match action | tournament_{id}_history |
| Global configuration | Points, legs, lanes, UI preferences | dartsGlobalConfig |
Configuration is never saved with a tournament. Tournament exports contain only the tournament's own data — not the config of the machine it was exported from. This means a tournament exported from one club's setup can be imported at another without any configuration bleed.
When a tournament is deleted, all of its keys are removed completely. No residue, no contamination between tournaments.
NewTon DC Tournament Manager has no server dependency for any of its core functionality. All data lives in the browser's localStorage — a sandboxed, domain-isolated storage area that persists across browser restarts and reboots without any network connection.
Every state change is saved immediately. There is no "save button" because there is no moment where unsaved state exists. If the browser crashes mid-tournament, the last saved state is fully intact and consistent.
See the Privacy Architecture page for the full storage model.
FS-2-1 = Frontside Round 2 Match 1, BS-FINAL = Backside Final), an auditable transaction log, and open-source code mean the system's behaviour is always inspectable.Honesty is part of reliability. These are the known constraints of the current architecture: