Two people on the same account never lose each other’s work.
Every change in Growth-OS goes through the server, in one transaction, exactly once. If you and a colleague edit the same account, the second save is told the record moved on instead of quietly overwriting it. If your connection drops and the app retries, you get the original answer back, not a second decision.
1
place that writes to our database
1
transaction for the record, its jobs and its receipt
3
kinds of retry key supported
Without a shared foundation, every team rebuilds these edge cases, differently.
Two people open the same account note, both save, and the later save wins the whole document. The reasoning someone typed out is simply gone, and nobody can say when. A version check turns that into a refusal you can see and resolve.
A weak connection on the train, a second tap on save, and now there are two expenses or two meeting records for the same thing. Merging them later is guesswork. A mutation receipt makes the second attempt return the first result.
A transcript extraction gets queued, then the save it belonged to fails. The job runs against a record that never existed. Queueing inside the same transaction means the job only exists if the change did.
The mechanism end to end, as implemented in the repository.
Bad input stops at the contract
Every write is parsed against a shared schema before it reaches the data. The same parse runs on the first attempt and on every retry.
Duplicates queue instead of racing
A database lock makes two identical requests take turns rather than collide. The server then checks whether this save already has a receipt.
Everything commits together
The record, its revision snapshot, any background work it triggers, and its receipt all land in one PostgreSQL transaction. All of it, or none of it.
Retries replay the receipt
A repeat request finds the receipt and gets the original answer and transaction ID back. Reusing the same ID for a different write is rejected rather than accepted.
Interactive example
This walkthrough demonstrates the implemented backend contract without using an account, credentials, or provider calls.
Interactive example
Step 1 of 4: Parse input
Deterministic sample data only. No account, provider, or network connection is used by the interaction.
Highlights
Nothing in the browser writes to our database. Each save crosses a shared contract, takes its identity from the session, and commits on the server.
Every save carries a mutation ID and leaves a receipt. Send it again and the server replays that receipt instead of creating a second row.
Records carry a version. A save built on an older version fails with a message saying it changed since it was loaded, so nobody silently loses a paragraph.
Engineering guarantees
This protects the write itself: identity, project scope, duplicates and ordering. Whether a decision is a good decision is still ours to judge, and rules specific to one record kind live in that feature’s own command.
The boundary above is code, not a claim. These files carry the contract:
src/server/transactions.tssrc/server/permissions.tsdocs/CONVENTIONS.mdThese capabilities share contracts and boundaries with this one.
The docs describe the same contracts this page demonstrates.