LeadRefinery — How the Platform Works

Shipping a change

Every improvement to the platform — a fix, a new screen, a corrected rule — must reach the host that serves real clients without ever being tested on real clients first. This page describes the path a change takes, and the check that stops a broken one before it arrives.

The path

  1. A person finishes a change and adds it to the project's shared history.
  2. The build-and-rehearse host builds it once. This is the only host that ever builds the platform's own software.
  3. The same host rehearses the change, using a full practice campaign that places no real call. The rehearsal must genuinely run: a check that reports success while doing nothing counts as a failure, not a pass.
  4. A person approves the change for production, but only if the rehearsal finished cleanly. Approval is one command, and it is a deliberate, separate act from writing the change itself.
  5. Production takes the exact same, already-built copy. It never builds its own version, so what runs in production is provably the same bytes that were just rehearsed.
  6. A health check confirms production is answering correctly immediately after it starts running the change. A deploy that reports success is not proof that production came back; the check is.
A change is pushed, then built once on a separate host. That host rehearses the change with a full practice campaign that places no real call. If the rehearsal does not finish cleanly, the change stops there and never reaches production. If it finishes cleanly, a person approves it, and production takes the exact same, already-built software rather than building its own copy. Rolling back moves production to an earlier approved build by the same path, nothing rebuilt; the calling machines move only when no lead's record would become unreadable.
A change that fails its rehearsal never leaves the build-and-rehearse host. Nothing reaches a real client by accident.

Why production never builds its own software

This was not always the design. Building the whole platform once used more than three and a half times a small production host's own memory. The surge was severe enough to crash the very tool doing the deploying, taking the host's control panel down with it, mid-build, having produced nothing. Two lessons followed:

  • A host sized for its normal, running workload cannot also build the platform. The two jobs do not fit on the same machine.
  • Building software and serving real clients must happen on different hosts, on principle, not only because of the memory involved. A host that builds its own software can never prove that what it serves is what was actually rehearsed.

So the build-and-rehearse host does both jobs — building and rehearsing — and production does neither. It only ever receives a finished copy.

Rolling back

Moving production back to an earlier, already-approved version uses the same path as moving it forward: point production at a different already-built copy, and confirm the health check afterward. Nothing is rebuilt, so a rollback takes minutes rather than the time a build would take.

One part of production cannot always go back. The machines that work through each lead's calling plan keep a written record of every step each lead has taken, and they re-read that record whenever they pick a lead up again. A plan that lasts weeks has usually been written by the newest version. An older version can fail to read it, and then that lead stops where it is until a version that can read it returns. So before a rollback moves those machines, the tooling compares the two versions and refuses if any record would become unreadable. In that case the screens and the web service go back on their own, and the calling machines stay on the newer version; or the fault is fixed and shipped forward instead. A LeadRefinery operator follows a written checklist for this decision.

What decides whether a change is safe to ship

The rehearsal is the one check that must pass before any change reaches production. It was chosen deliberately over a smaller, faster check, because it is the only test that exercises the platform exactly as a real client would use it — the whole calling journey, its pacing, and every safety check — while placing zero real calls. A conversation-quality change is judged separately, by the evaluation toolkit, because the voice agent's own configuration lives with the voice provider, not inside this rehearsal.