--- title: "voxcog: produktbeslutninger med sporbart underlag" description: "Hvordan voxcogs beviskjede gikk fra prototype til MVP: 108 skrevne spesifikasjoner, tre dokumenterte beslutninger og en dreining som ble arkivert." url: https://torn.studio/no/arbeid/voxcog-beviskjeden-produktbeslutninger locale: no published: 2026-08-31 updated: 2026-08-26 --- # voxcog: produktbeslutninger med sporbart underlag > **Kort svar:** Torn Studio drev voxcogs produktarbeid fra prototype til MVP. Hver funksjon ble planlagt som en skrevet spesifikasjon — 108 av dem ligger igjen i kodebasen — og hver retningsbeslutning ble skrevet ned med alternativene og hva valget kostet. En dreining i juni 2026 smalnet fem søyler til én pipeline. **Kunde:** voxcog · **Levert:** 2026-08-26 **Studioets forhold til kunden:** voxcog er et produkt Torn Studio har bygget og eier en andel av. Studioet hadde ansvaret for produktledelse, arkitektur og bygging fram til overleveringen i august 2026. ## Oppdraget voxcog trengte å gå fra en prototype med fem parallelle søyler til et produkt med én tydelig kjerne, og trengte å gjøre det slik at begrunnelsen bak hvert valg finnes igjen når neste person leser koden. ## Det som gjorde det vanskelig - Fem jevnbyrdige søyler gjorde produktet vanskelig å demonstrere og vanskelig å beskrive på én linje, noe som er et posisjoneringsproblem før det er et byggeproblem. - Flere parallelle arbeidsspor mot samme database gjør sekvensnummererte migrasjoner utrygge, fordi to grener hver for seg velger samme neste nummer. - Produktet håndterer kundenes interne materiale, så personvernet måtte være på plass allerede før lansering. ## Tall som lar seg telle | Tall som lar seg telle | | | | --- | --- | --- | | 108 | skrevne spesifikasjoner | Trettito aktive og syttiseks arkiverte mapper. Hver av dem bærer designvalget og trinnene, så en levert funksjon kan leses bakover. | | 3 | dokumenterte retningsbeslutninger | Hver med kontekst, alternativene som ble veid og prisen for det valgte. Formatet krever at kostnaden skrives ut. | | 102 | databasemigrasjoner | Tidsstemplet, med en test som feller byggingen på et duplisert eller sekvensnummerert prefiks. Regelen finnes fordi parallelle grener ellers velger samme nummer. | | 6 | juridiske underlag før lansering | Behandlingsprotokoll, konsekvensvurdering, hendelsesplan, databehandleravtale, personvernerklæring og brukervilkår. | ## Slik ble det gjort ### En skrevet spesifikasjon før hver bygging Hver funksjon fikk sin egen mappe med designspesifikasjon og trinnvis implementeringsplan før koden ble skrevet. Da arbeidet var levert, ble mappen flyttet til arkivet, så kodebasen bærer både det som bygges nå og begrunnelsen bak det som allerede er bygget. ### Beslutninger med alternativer og pris Retningsbeslutninger ble skrevet som egne dokumenter med konteksten, alternativene som ble veid og hva det valgte alternativet kostet. Formatet tvinger fram den vanskelige setningen: hva ble dårligere av denne beslutningen. ### Dreiningen ble lagt ved siden av det den erstattet Da produktet i juni 2026 ble smalnet fra fem søyler til én lineær pipeline, ble den gamle strategien flyttet til et datert arkiv og den nye lagt ved siden av. Den som leser i dag ser begge og kan vurdere om begrunnelsen fortsatt holder. ### Sporbarhet som produktets egen mekanisme Kjeden som ble bygget speiler arbeidsmåten: hvert signal peker på sin eksakte kilde, hver innsikt på sine signaler, og nytt materiale som motsier et signal flagger alt nedstrøms som må vurderes på nytt. **Teknologi:** Next.js 16, Supabase, Postgres, pgvector, Reciprocal Rank Fusion, Claude Sonnet 4.6, MCP ## Hva beviset rekker til Dette viser produktledelse som legger igjen spor: beslutninger kan leses bakover og begrunnelsen finnes igjen. Det sier ingenting om hvorvidt markedet vil ha voxcog — plattformen ble overlevert før lansering, og det spørsmålet står åpent. ## Vanlige spørsmål ### Hva er en beviskjede i praksis? Fire ledd som peker nedover: et signal peker på sin eksakte kilde, en innsikt på sine signaler, en beslutning på sine innsikter og et prinsipp på det som har vist seg å holde. Hvert ledd bærer en lenketype og en konfidens. ### Hva skjer når nytt materiale motsier en tidligere antakelse? Kjeden traverseres framover og flagger hver innsikt, beslutning og prinsipp som hviler på signalet som nå er i tvil. Det som er blitt utdatert blir synlig i selve kjeden. ### Hvorfor skrive en spesifikasjon når AI likevel skriver koden? Spesifikasjonen er det som gjør byggingen mulig å gjennomgå. Et verktøy som får en tydelig avgrensning og en rekkefølge av steg produserer noe som kan leses og verifiseres, og mappen som blir igjen forklarer valget for neste person. ### Hvordan avgjør dere hva som skal ut av et produkt? Ved å skrive ned hva det koster å beholde det. Intervjusystemet var ferdig og virket, men det trakk fokus fra det som bar produktet, så det havnet bak et flagg med begrunnelsen notert. ### Kan dere drive produktarbeid for oss på samme måte? Ja. Arbeidsmåten er uavhengig av produktet: en skrevet spesifikasjon før hver bygging, retningsbeslutninger med alternativer og pris, og et arkiv som gjør at begrunnelsen finnes igjen når teamet byttes ut. ### Hvor mye av dette er AI-generert? Utkastene trekkes med AI-verktøy, og hver spesifikasjon og beslutning leses og redigeres av et menneske før den gjelder. Det som avgjør kvaliteten er avgrensningen og gjennomgangen, og den delen er fortsatt manuell.