A Day in the Life of a vCon.

To see the Conserver in normal operation, follow one conversation as it is captured, transformed, and handed to a business team as something they can actually use. For this example, assume the Conserver is configured to take conversations from a FreeSWITCH phone system, transcribe them, look for a particular subject — product recalls — and send the ones that match to a PostgreSQL table for the operations team.

Capture, transcribe, detect, project

Step by step

1. A conversation happens

   A customer and an agent talk over FreeSWITCH. A FreeSWITCH adapter is running that monitors calls and requests recordings.

2. The adapter builds a vCon

   When the call ends, the adapter uses the call data — parties, recordings — to create a vCon. It POSTs the vCon to the Conserver's API, naming the Redis lists that feed each chain. Alternatively, the vCon can be inserted into Redis directly, then its UUID added to each chain's ingress list.

3. It is stored under its own key

   The vCon is stored in Redis as a JSON object under the UUID of the newly created vCon. By convention the key follows the pattern vcon:uuid, such as vcon:7665-343535-58575-333.

4. The adapter leaves a trail

   Alongside the standard parts — the dialog and parties — the adapter adds an attachment describing what created the vCon and details useful for debugging. That attachment travels inside the vCon throughout its life, unless it is explicitly stripped off later.

5. The Conserver ticks the chains

   On a periodic timer, or triggered by an external API call, the Conserver iterates over all processing chains. Each chain has a Redis list of vCons to process. On each tick it creates a task per ID read from the list. Horizontal scaling comes from a single Redis cluster connected to multiple Conservers.

6. Link one: transcription

   Links expect a vCon UUID in and return vCon UUIDs out, so they can be chained freely, the output of one feeding the next, interchangeable in order or vendor. The transcription link (Whisper or Deepgram) takes the dialog audio and transcribes it, adding a complete transcription with a confidence score and timestamp for every word into the analysis section. It updates the stored vCon in place, using Redis to avoid copying the large media objects.

7. Link two: recall finder

   The recall-finder link loads the transcription and looks for the word “recall” in the conversation. If it does not find it, the link simply exits without creating any message for the downstream plugin, effectively ending the chain for that vCon. If it does, this is now a recall conversation, and worth acting on.

8. A projection is written

   When the destination has a fixed schema — a Postgres table, a spreadsheet, a no-code tool — a projection is created first. A projection is a simple key-value view of the fields that matter for the use case. Here that is the transcription, the agent, the customer, and when the conversation happened: four columns, one row. It is added to the vCon just as the transcription analysis was.

9. Link three: the Postgres projection

   The final link looks for projections on the vCon, then upserts a row into the configured Postgres table. From the perspective of the business users, they simply see rows of transcribed conversations that match their criterion. Data projections, like adapters, absorb the differences between destinations, so relational databases, no-code tools, and spreadsheets each get what they expect.

That is the whole idea. Adapters absorb the differences between where conversations come from. Links do one job each and pass a UUID along. Projections absorb the differences between where the data needs to land. And because a link can be reused within and between chains, the same pipeline is reordered or re-pointed at a new vendor without rewriting anything around it.