LeadRefinery — How the Platform Works

Getting back after a loss

This page explains what happens if a server or the data is lost, and how the platform comes back. The platform keeps two separate copies, away from the running machines. One copy is the data. The other is the plan of the servers. If the servers are lost, neither copy is lost.

Where the platform runs

Production runs on three servers in Ashburn, in the United States. Each server has one job:

A separate practice system, called staging, runs in Germany. No real call is placed from it.

What is protected, and how

Five controls protect the servers and the data. Each one was checked on the running system on 26 October 2026:

  • The databases hold the leads, the call records, and the ten-year compliance record. The platform copies them every night at 03:15 to off-site storage in Helsinki, Finland — a different country from where they run. The store keeps the last 30 nightly copies, plus one copy a month for a year. It keeps old versions, so a bad copy cannot replace a good one.
  • A stop-calling request gets its own, tighter copy on top of the nightly one: every five minutes, the platform ships every new stop request to the same locked, off-site store that holds the signed agreements. A restore from the nightly copy alone could lose a day's worth of stop requests; reading this separate copy back in after a restore limits that loss to about five minutes, so a rebuilt platform does not call someone who had already asked to stop.
  • The plan of the servers — which servers, disks, private network and firewalls exist — is written as code. The platform can rebuild the whole setup from this plan, from nothing.
  • Each production server also makes its own daily disk backup. Delete protection is on, so no one can remove a server or its disk by accident.
  • A recovery sign-in key is registered, so the platform can sign in to rebuilt servers.
On the left, production in Ashburn, in the United States: three servers (app and control room, call-workflow worker, databases) and a data disk. Two copies leave it. The nightly data copy goes to off-site storage in Helsinki, Finland, which the diagram marks as a different country. The plan of the servers is written as code and kept in version control. The message is that both copies live somewhere other than the running servers.
Two copies leave production and are kept elsewhere. One is the data, copied to Helsinki every night. The other is the plan of the servers, written as code. Note that both live in a different place from the running machines, so losing the Ashburn servers loses neither.

The road back

If the platform must rebuild from nothing, it follows these steps, in order:

  1. Rebuild the servers from the plan.
  2. Put back the host settings and secrets. The platform keeps them in the password manager.
  3. Restore the databases from the latest off-site copy.
  4. Point the web addresses at the new servers.
  5. Check that everything works, then tell people the platform is back.
A left-to-right flow of the rebuild after a loss: rebuild the servers from the plan, restore the settings and secrets, restore the databases from the Helsinki copy, point the web addresses at the new servers, then check it works and tell people. A bracket across the flow marks about three to four hours for a full rebuild. A note by the restore-databases step marks at most about 24 hours of data at risk.
The rebuild runs in a fixed order. Note the two promises marked on the flow: a full rebuild takes about three to four hours, and at most about 24 hours of data can be lost, because the platform takes the copy once a night.

The two promises

  • At most about 24 hours of data can be lost. The platform takes the copy once a night, so the newest changes since the last copy are the ones at risk. This is the recovery point. A stop-calling request is the one exception: its own five-minute copy limits its own loss to about five minutes, not 24 hours.
  • A full rebuild takes about 3 to 4 hours. This is the recovery time.

How we know it works

The platform tested recovery on 26 October 2026. These are the real results:

  • The latest nightly copy was restored into a throwaway database and checked against the live one. All 78 data tables were present. The slow-changing tables matched exactly. The ten-year compliance record came back complete. The live copy was only ahead by that day's activity, which is expected.
  • A server was also built from the plan, from nothing, signed in to, and then removed. This proved the plan rebuilds a working machine.

What is not copied, on purpose

Some things are left out of the copies on purpose, because the platform can make them again or does not need them:

  • The practice system (staging). Nothing on it is a record.
  • The store of program images. The platform can rebuild it.
  • The short-lived cache.

Signed agreement documents are protected a different way. They go to their own write-once store. No one can delete it, not even the account owner, until the retention date.