Så bygger jag ett publishing gate för AI-content
Ett publishing gate ska svara på en enda fråga: kan den här artikeln publiceras nu? Inte "är draften ganska bra?" och inte "kan en editor fixa resten?".
Ett publishing gate ska svara på en enda fråga: kan den här artikeln publiceras nu? Inte "är draften ganska bra?" och inte "kan en editor fixa resten?".
Jag fick lära mig det genom ett faktiskt kontraktsfel i BijoyIQ-fabriken. Publisher Gate gav READY samtidigt som rapporten fortfarande krävde synliga källor och en publication-day freshness check. Då betydde READY egentligen "nästan klar". Det är ett farligt state.
READY måste vara strikt
Jag definierar numera READY som att inga obligatoriska release-actions återstår. Om en material claim fortfarande behöver verifieras är status inte READY. Om externa källor måste renderas är status inte READY. Det gör state-maskinen begriplig även för automation.
Gaten ska inte reparera
Publisher Gate får bara bedöma. Den får inte skriva om ett unsupported claim, lägga till en källa eller skapa first-hand evidence. Om den hittar ett fel ska artikeln tillbaka till den stage som äger problemet. Annars blir gaten ännu en writer och kvalitetskedjan kollapsar.
Mina hard requirements
Ett minimalt contract kan vara:
Deterministiska delar valideras i kod. Bedömningsfrågor får specialistreview.
Publicering är en högre risk än drafting
OpenAI:s agentguide rekommenderar särskild mänsklig kontroll för high-risk eller irreversibla actions (guiden och adressen kan uppdateras över tid). Jag använder samma tanke för content: research och draft kan automatiseras långt, men publicering är en extern handling som förtjänar hårdare krav.
Det betyder inte att en människa måste klicka på varje artikel för alltid. När evals visar stabil kvalitet kan delar automatiseras, men release-kontraktet ska vara lika tydligt.
Gaten behöver freshness
En artikel kan ha passerat fact-check för tre veckor sedan men innehålla ett pris eller en produktfeature som ändrats. Därför kan Publisher Gate kräva en freshness recheck beroende på claim class. Poängen är att den kontrollen ska vara utförd innan READY sätts.
Gaten ska läsa hela provenance-kedjan
Jag vill kunna följa final paragraph -> claim IDs -> evidence verdicts -> source IDs -> retrieved/verified timestamps. Om kedjan bryts ska gaten blockera det materiella påståendet.
En gate skyddar också mot content-scale-problem
Google accepterar användning av generativ AI, men varnar för massproduktion utan mervärde. Ett publishing gate är därför också ett throughput-reglage. Bara för att fabriken kan generera 50 drafts betyder det inte att 50 URL:er ska gå live.
När READY är strikt blir publiceringsvolym ett resultat av kvalitetskapacitet, inte writer-kapacitet.
Det är den viktigaste egenskapen i min gate: den ska kunna säga nej. Ett system där allt förr eller senare blir READY har ingen riktig gate. Det har bara en kö.