Research layer vs writing layer: varför jag separerar dem

Research layer vs writing layer: varför jag separerar dem handlar för mig mindre om en enskild prompt och mer om hur man gör ett återkommande AI-arbete granskningsbart. När research och skrivande sker i samma kontext kan texten börja formulera en slutsats innan källbilden är klar, och då blir det svårt att avgöra om en formulering kommer från källan, från modellens bakgrundskunskap eller bara från en snygg syntes. När jag bygger för egen produktion gör jag därför antaganden, evidens, state och stoppregler synliga i ett separat lager innan någon artikelprosa tillåts. Resultatet blir mindre magiskt, men betydligt lättare att lita på, felsöka och förbättra.

Ett dokument är inte samma sak som evidens

Jag gör den här kontrollen som en egen artefakt i stället för som en mental checklista. För research layer vs writing layer: varför jag separerar dem betyder det att input, beslut och output kan granskas i efterhand. Jag vill kunna peka på varför ett steg passerade, vilket underlag som användes och vad som hade fått det att blockeras. Det gör också att samma kontroll kan köras om efter en ändring utan att hela resonemanget behöver uppfinnas på nytt.

Det viktiga är inte att processen ser strikt ut på papper. Den ska reducera en konkret felmod. När en kontroll inte längre fångar ett verkligt problem tar jag hellre bort den än låter den leva kvar som ceremoni.

Researchlagret ska vara fult men spårbart

Researchanteckningar behöver inte vara läsvärda. De ska vara granskningsbara. Jag föredrar claim IDs, source URLs, retrieval date, citatfragment inom rimliga gränser och en kort tolkning. Ett bra researchlager kan se mer ut som ett dataunderlag än en artikel. Det är en styrka eftersom samma evidens senare kan återanvändas i andra format.

Jag försöker dessutom skilja mellan sådant modellen får bedöma och sådant systemet kan avgöra deterministiskt. Ju tydligare den gränsen är, desto lättare blir det att felsöka när resultaten varierar mellan körningar.

Beslutsträd gör gränserna testbara

Skillnaden mellan modellbedömning och deterministisk kontroll fungerar bäst när den byggs som ett beslutsträd, inte som en instruktion i löptext. Ett krav som "osäkerhet ska hanteras" måste brytas ned till ett observerbart tillstånd och ett val: om källor konfliktar → markera CONFLICT → stoppa publicering → eskalera. Jag definierar därför vilka tillstånd som spelar roll — verifierad, kvalificerad, olöst, konflikt, blockerad — och vilka evidenskrav som flyttar systemet mellan dem.

Trösklar som kan avgöras deterministiskt ska inte gömmas i prosa. Saknas två obligatoriska filer behöver ingen modell resonera om readiness; koden kan returnera BLOCKED direkt. Det betyder inte att allt ska hårdkodas — modellen får fortfarande äga gråzonen, bedöma relevans, sammanfatta evidens eller föreslå nästa steg. Trädet bestämmer bara vilket utrymme den får göra det inom, och varje gren behöver minst ett positivt och ett negativt testfall. Annars vet jag inte om systemet faktiskt följer beslutsträdet eller bara råkar ge rätt svar på det exempel jag testade med.

Writing layer får inte bredda sanningen

Writerns uppgift är att göra godkänd information begriplig, inte att komplettera luckor. Jag låser därför vilka claims som får användas och vilken säkerhetsgrad de har. En QUALIFIED claim får inte bli ett kategoriskt påstående bara för att meningen flyter bättre. En UNRESOLVED claim ska antingen bort eller uttryckligen markeras som osäker.

Det här skapar lite mer arbete i första versionen, men skalan ändrar ekonomin. När samma flöde används på tiotals eller hundratals outputs blir spårbarhet, återanvändbara testfall och tydliga stoppregler billigare än manuell efterkontroll.

text

A017 checkpoint 3input -> validation -> evidence -> decision -> stateon failure -> BLOCKED / revise upstream

Separationen gör redigering säkrare

När facts ligger i ett separat lager kan en editor arbeta aggressivare med rytm och struktur utan att samtidigt behöva avgöra vad som är sant. Efter redigeringen kan systemet jämföra texten mot claim ledger igen. Det är mycket svårare när artikelutkastet själv är den enda representationen av källmaterialet.

För mig är det en varningssignal när ett kriterium i writing layer bara säger att något ska vara "rimligt", "bra" eller "korrekt" utan att claim ledger kan peka på vad det betyder i just den uppgiften. Då bryter jag ned kriteriet till konkreta exempel innan jag litar på det i produktion.

Det gör källuppdateringar möjliga

Om en myndighet, API-dokumentation eller produktfunktion ändras vill jag kunna hitta vilka claims som påverkas. Med ett strukturerat researchlager kan source freshness bli en underhållsfråga i stället för en manuell omläsning av hundratals artiklar. Det är särskilt viktigt för regler, belopp, modellfunktioner och allt annat som kan bli gammalt snabbt.

Jag dokumenterar även scope på varje regel i researchlagret, för en regel utan angivet giltighetsområde tenderar annars att spridas till uppgifter där den aldrig var tänkt att gälla — särskilt när flera Skills eller referenser kombineras i samma session.

Research och SEO har olika mål

SERP-research berättar vilket informationsbehov som finns. Evidensresearch berättar vad vi kan säga och med vilken säkerhet. Jag blandar inte ihop dem. En konkurrent kan indikera en fråga vi bör besvara, men konkurrenten blir inte automatiskt vår sakliga källa. Det här förhindrar att SEO-lagret börjar styra fakta.

Ett konkret handoff-kontrakt

Min handoff från research till writing innehåller minst approved claims, blocked claims, first-hand evidence, required caveats och source ledger. Writern får inte börja om bara för att skapa en bättre berättelse. Om arkitekten vill ha en sektion som kräver en ny claim går jobbet tillbaka till research.

Ett praktiskt exempel på hur den här uppdelningen ser ut i verktygsvalet: jag använder NotebookLM när uppgiften är centrerad kring en avgränsad källsamling och jag vill hålla exploreringen nära de uppladdade källorna — jämföra teman, navigera en dokumentsamling, förstå ett paket innan något skrivs. När researchen i stället ska bli ett system — filstruktur, scripts, Skills, evals eller kod som kan byggas och testas — passar Claude Code bättre. NotebookLM blir då explorationslager och Claude Code implementationslager. Verktygsvalet behöver inte vara ideologiskt; det följer bara var i kedjan, research eller writing/system, arbetet befinner sig.

När jag inte behöver två lager

För enkla låg-risk-texter kan separationen vara onödig. En kort produktbeskrivning från ett fast faktablad eller en intern statusuppdatering kan ofta skrivas direkt. Jag använder separationen när faktamängden är större, källorna kan ändras, first-hand experience är viktig eller kostnaden för ett fel är mer än kosmetisk.

Den praktiska vinsten är felsökning

När en artikel är fel kan jag fråga om felet kom från research, evidensbedömning, outline, wording eller editorial pass. Utan lager svarar man ofta bara "AI:n skrev fel". Det är för grovt för att förbättra ett system. Separationen gör varje fel till en möjlig regression och därmed till något man kan testa.

Min tumregel

Om en text ska leva länge, uppdateras, innehålla flera verifierbara påståenden eller publiceras under ett varumärke bygger jag research som en egen produktartefakt. Writing layer får sedan optimera begriplighet, tempo och struktur inom dessa gränser. Det är långsammare per första artikel men mycket snabbare när systemet börjar producera många.

Ett exempel på hur jag dokumenterar beslutet

Jag avslutar varje större steg i det här flödet med ett kort beslut som går att läsa utan resten av agentens resonemang: vad som kontrollerades, vilket underlag som fanns, vilka osäkerheter som återstår och vilket nästa state är. Den typen av handoff är medvetet tråkig. Den ska vara stabil nog för att nästa agent eller en människa ska kunna fortsätta utan att behöva tolka en lång chattlogg mellan research- och writinglagret.

text

decision: PASS | BLOCKED | REVISEevidence: [source IDs / FH IDs]remaining uncertainty: [...]next owner: [...]

När jag inte kan fylla i de fälten är problemet oftast upstream, i researchlagret snarare än i skrivandet. Jag föredrar då att stanna flödet framför att låta writing layer skriva fram en snyggare version av ett oklart beslut.

Slutsats

Grundprincipen bakom hela den här uppdelningen är att en researchprocess blir användbar först när den går att återupprepa utan att jag förlitar sig på att modellen råkar resonera likadant nästa gång. Det kräver inga fler agenter eller mer kod i sig — det kräver tydliga gränser mellan fakta, bedömning, språk och handling. Med de gränserna på plats i researchlagret kan jag vara mer generös med writing layers styrkor, rytm och struktur, utan att samtidigt ge upp kontrollen över vad som faktiskt är sant.

Uppdelningen ger också ett gemensamt språk för kvalitet. I stället för att säga att en artikel "känns fel" kan jag peka på saknad evidens i researchlagret, en för bred trigger i beslutsträdet, fel ägare av ett beslut eller en state transition som skedde utan godkänd handoff till writing layer. Den precisionen är viktig när flera personer eller agenter arbetar i samma system.

Separationen gör det också lättare att byta ut modellen som gör skrivandet. Om all kvalitet satt i writerns specifika formuleringar skulle ett modellbyte vara riskabelt. När kvaliteten i stället sitter i claim ledger, handoff-kontraktet, evals och de deterministiska kontrollerna i researchlagret går det att testa en ny writing-modell mot samma uppgift och se exakt vad som förändras.

Kostnad är ytterligare ett skäl att hålla lagren åtskilda: ett steg som bara klassificerar ett litet schema behöver sällan samma modell som själva researcharbetet. När research layer och writing layer är uppdelade blir den routingen möjlig utan att kompromissa med den del där högre kvalitet faktiskt behövs — evidensarbetet.

Till sist försöker jag alltid spara ett par exempel på fel som nästan gick igenom handoffen från research till writing. Det lyckade exemplet är lätt att dokumentera, men det är de nästan-passerade felen som visar vilka claim-luckor eller edge cases nästa version av researchlagret måste fånga.