---
title: "voxcog: product decisions with a traceable trail"
description: "How voxcog’s evidence chain went from prototype to MVP: 108 written specs, three recorded decisions, and a pivot whose old strategy stayed in the archive."
url: https://torn.studio/en/work/voxcog-evidence-chain-product-decisions
locale: en
published: 2026-08-31
updated: 2026-08-26
---

# voxcog: product decisions with a traceable trail

> **Short answer:** Torn Studio ran voxcog’s product work from prototype to MVP. Every feature was planned as a written spec — 108 of them are still in the repository — and every directional call was written down with its options and what the choice cost. A pivot in June 2026 narrowed five pillars to one pipeline.

**Client:** voxcog · **Delivered:** 2026-08-26

**The studio’s relationship to the client:** voxcog is a product Torn Studio built and holds a stake in. The studio ran product management, architecture and the build through to handover in August 2026.

## The brief

voxcog needed to move from a prototype with five parallel pillars to a product with one clear core, and to do it so the reasoning behind each call survives for whoever reads the code next.

## What made it hard

- Five co-equal pillars made the product hard to demonstrate and hard to describe in one line, which is a positioning problem before it is a build problem.
- Several parallel work streams against one database make sequentially numbered migrations unsafe, because two branches each pick the same next number.
- The product holds customers’ internal material, so data protection had to be in place before launch.

## Figures a reader can count

| Figures a reader can count | | |
| --- | --- | --- |
| 108 | written specs in the repository | Thirty-two active folders and seventy-six archived. Each carries the design call and the steps, so a delivered feature can be read backwards. |
| 3 | recorded directional decisions | Each with context, the options weighed and the price of the one chosen. The format requires the cost to be written out. |
| 102 | database migrations | Timestamped, with a test that fails the build on a duplicate or sequential prefix. The rule exists because parallel branches otherwise pick the same number. |
| 6 | legal documents before launch | Record of processing, impact assessment, breach response plan, data processing agreement, privacy policy and terms of service. |

## How it was done

### A written spec before every build

Every feature got its own folder with a design spec and a step-by-step implementation plan before any code was written. Once delivered, the folder moved to the archive, so the repository carries both what is being built now and the reasoning behind what is already built.

### Decisions with options and a price

Directional calls were written as their own documents with the context, the options weighed and what the chosen option cost. The format forces the hard sentence: what got worse because of this decision.

### The pivot was filed beside what it replaced

When the product narrowed from five pillars to one linear pipeline in June 2026, the old strategy moved to a dated archive and the new one was filed next to it. Anyone reading today sees both and can judge whether the reasoning still holds.

### Traceability as the product’s own mechanism

The chain that was built mirrors the way it was built: every signal points at its exact source, every insight at its signals, and new material that contradicts a signal flags everything downstream that needs revisiting.

**Stack:** Next.js 16, Supabase, Postgres, pgvector, Reciprocal Rank Fusion, Claude Sonnet 4.6, MCP

## The limits of this proof

This shows product management that leaves a trail: decisions can be read backwards and the reasoning survives. It says nothing about whether the market wants voxcog — the platform was handed over before launch, and that question is open.

## Common questions

### What is an evidence chain in practice?

Four links pointing downward: a signal points at its exact source, an insight at its signals, a decision at its insights, and a principle at what has proven durable. Every link carries a type and a confidence.

### What happens when new material contradicts an earlier assumption?

The chain is traversed forward and flags every insight, decision and principle resting on the signal now in doubt. What has gone stale becomes visible in the chain itself.

### Why write a spec when AI writes the code anyway?

The spec is what makes the build reviewable. A tool given a clear boundary and an ordered set of steps produces something that can be read and verified, and the folder left behind explains the call to the next person.

### How do you decide what to take out of a product?

By writing down what keeping it costs. The interview system was finished and working, but it pulled focus from what carried the product, so it went behind a flag with the reason recorded.

### Can you run product work for us the same way?

Yes. The method is independent of the product: a written spec before every build, directional calls with options and a price, and an archive that keeps the reasoning available when the team changes.

### How much of this is AI-generated?

Drafts are pulled with AI tooling and every spec and decision is read and edited by a person before it stands. What decides quality is the boundary and the review, and that part is still manual.