CHECK THEN WRITE60,461 / 100,000
Check first, write later
0.60461Both requests first saw balance 100. Each amount was at most 100, so both were approved. A pair counted as overcommitted when a + b > 100.
A sampled synthetic counterexampleTOWOW SYNTHETIC RESULT · R2
The balance was 100. Both requests said “enough.”
When checking and writing happen at different moments, two requests can read the same stale balance and each receive an individually correct approval.
Across 100,000 synthetic request pairs, this model produced 60,461 overcommitments. The 60.461% is not a real incident rate. It is a deliberately exposed concurrency counterexample.
- 100,000
- synthetic request pairs
- 60,461
- check-then-write overcommitments
- 0
- encoded ideal reservation result
Design conclusion
Drafts can be eventually consistent. A final commitment over scarce resources needs one moment that counts.
01 · THE SYNTHETIC WORLD
State the model before celebrating the number.
This was a historical synthetic generator from 2026-07-24, not production telemetry, and it did not call language models. It asked one narrow question: what happens when two requests read a stale balance before either update becomes visible?
- B = 100
- The shared balance was fixed at 100.
- a, b ∼ U(10,100)
- Two request amounts were independently sampled from a continuous uniform distribution.
- 100,000 pairs
- The sample proportion estimated the conflict probability.
- seed 20260724
- Four historical experiments shared one RNG, so call order affects exact reproduction.
02 · WHAT THE TWO ARMS ACTUALLY DID
One arm sampled. The other wrote down zero.
That difference controls the claim. The check-then-write arm performed numerical sampling. The reservation arm did not run a database or concurrent transaction.
IDEAL RESERVATIONnp.zeros(trials)
Ideal linearized reservation
0The code directly set the reservation overspend array to zero, expressing the invariant that successful reservations cannot exceed B.
Zero by construction, not observationANALYTIC CHECK≈ 0.604938
Exact probability
49 / 81A geometric area calculation gives the exact probability. The Monte Carlo result is close, so the sample agrees with this generator.
Generator calibration, not product proofThe critical correction
Do not report “zero failures for serializable reservation in 100,000 concurrent trials.” There was no database, lock, transaction isolation, thread race, process race, or fault injection.
03 · THE MISSING LINEARIZATION POINT
Every local decision was right. The combination was still wrong.
No request needed to lie. The two approvals simply lacked one shared moment that counted.
- READ 01
Request A read balance 100. Request B read the same stale balance 100.
- CHECK 02
A was no larger than 100, so it passed. B was also no larger than 100, so it passed.
- WRITE 03
The two local approvals moved toward write without reserving capacity against each other.
- CONFLICT 04
Whenever a + b > 100, two individually valid decisions produced a joint overcommitment.
“There was enough when I checked” is not evidence of a final commitment. The system must prove that capacity became exclusive at the moment the commitment counted.
04 · WHY THE NUMBER IS ABOUT 60.5%
The 60.461% is not a black-box metric.
Subtract 10 from a and b. The sample space becomes a square with side 90. The safe region x + y ≤ 80 is a right triangle. Everything else is overcommitment.
Historical generator result
60,461 samples satisfied a + b > 100.
Exact probability 0.604938…
(8100 − 3200) / 8100 = 4900 / 8100.
Their agreement is not real-world validation. It only shows consistency between the historical sample and this two-request, fixed-balance, uniform-distribution model.
05 · A REPRODUCTION TRAP
The same seed gave a different number when run alone.
The historical script shared one RNG across four experiments and ran the concurrency experiment last. Calling only this experiment with seed 20260724 gives 60,370 / 100,000, or 0.60370. Replaying the full call order reproduces 0.60461.
- 01
Historical summary CSV
0.60461
- 02
Isolated same-seed rerun
0.60370
- 03
Full RNG-order replay
0.60461
- 04
Original 100,000 a,b pairs
Not retained
- 05
Code, seed, and summary
Still auditable
We can say the result was reconstructed from code and RNG order. We cannot say the original samples were audited row by row. Reconstructed data must not masquerade as retained raw data.
06 · WHAT ZERO WOULD REQUIRE IN REALITY
An invariant needs a real mechanism to protect it.
The ideal reservation argument is straightforward: atomically increase reserved only when capacity remains, and successful reservations cannot exceed B. A real system must still prove that this atomic boundary exists.
- 01
Reserve
Hold capacity exclusively
- 02
Commit
Turn the hold into a final commitment
- 03
Release
Return capacity after failure or cancellation
- 04
Expire
Handle abandoned and timed-out holds
- 05
Recover
Preserve ordering across faults and retries
If reserve is only sequential reads and writes in an in-memory dictionary, it proves nothing about threads, processes, databases, or consistency across failure domains.
07 · TOWOW × FLOWNESS
The protocol defines commitment. The Harness proves what happened.
Bind scarce resources and Authority before Commitment
Scarce capacity cannot depend on separate claims of availability. A relation must say who can reserve which resource version, when the hold becomes a commitment, and who can release it.
Preserve the reserve, commit, and release evidence chain
EventLog, Commit Gates, and target-native readback can preserve causality and outcomes. A Harness cannot magically make a non-atomic backend atomic.
Together, the system needs both the relational meaning of commitment and fresh evidence from the target that actually owns the capacity.
08 · CLAIM BOUNDARY
The counterexample is strong. Its radius is small.
Supported
- Separating check from update creates a clear overcommitment counterexample.
- Under this distribution, the conflict is not a rare edge case.
- A truly linearized reservation can preserve the capacity invariant by induction.
- Final commitments over scarce resources need atomic reservation or an equivalent mechanism.
Not supported
- The real-world overselling rate is not 60.461%.
- No database, platform, or ToWow implementation was shown to achieve zero overcommitment.
- The study says nothing about performance, availability, regional faults, or recovery.
- A synthetic concurrency counterexample is not product-closure or commercial-value evidence.
Materials and evidence level
Retained materials include generator code, the fixed seed, historical call order, a two-row summary CSV, a manifest copy, and SHA-256 checksums. The 100,000 original request pairs, per-trial decisions, transaction logs, schedules, and environment lock were not retained.
09 · NEXT EXPERIMENT
The next experiment cannot be another array of zeros.
A real comparison needs a barrier that forces concurrent interleaving, actual check-then-write and database-transaction arms, and retained commit, abort, retry, lock-wait, isolation, latency, fault-recovery, and multi-seed results.