# dumortier-marketing-ai-os-verification-2026-08-12

## Veille

Erfahrungsbericht, veröffentlicht auf **LinkedIn Pulse** am **12. August 2026** von **Guillaume Dumortier** in seinem Newsletter *Growth Marketing Fit*, mit dem Untertitel *„Four layers, a lot of rebuilding, and the failure modes nobody warns you about"*, ~2.500 Wörter. Thema: ein internes KI-System, gebaut **in Claude** für ein Marketingteam von rund sechzig Personen – etwa dreißig Content- und Sales-**Skills**, ein Dutzend **Source-of-Truth-Module**, **sieben Agenten, von denen sechs ausschließlich Arbeit prüfen statt sie zu produzieren**, ein **Plugin** für alle, die im Terminal arbeiten, eine **Browseranwendung**, die dasselbe Wissen für alle anderen bereitstellt, und eine Orchestrierung, die drei oder vier Assets zu einem *campaign bundle* verkettet. Die These wird früh formuliert: Die Qualität eines KI-Outputs entscheidet sich nicht im Moment der Generierung, sondern durch das, was das System vorher weiß, und durch das, was anschließend mit dem Entwurf geschieht – *„The generation step in the middle is the easy part. It's also the only part most teams have built."* Daraus ergeben sich vier Schichten: **Truth** (fast niemand baut sie), **Production** (jeder), **Verification** (fast niemand), **Internal distribution** (*„where good systems die of neglect"*). Zwei Fehlermechanismen tragen den Artikel. **(A) Das nackte Closed-World-„pass" des Prüfers**: Ein Fact-Checker, der auf Produktdokumentation gestützt ist, erhält einen Entwurf mit einer Behauptung über ein anderes Produkt, das von seinen Quellen nicht abgedeckt wurde – er liefert ein *„pass"*, nicht weil die Behauptung wahr war, sondern weil ihr nichts widersprach. *„It didn't just miss the error, it certified it."* Lösung: ein nacktes Urteil verbieten und von jedem Bericht verlangen, die **eigene Abdeckung** offenzulegen – wie viele Behauptungen geprüft wurden, wie viele mit Quellen abgeglichen werden konnten, welche außerhalb seiner Zuständigkeit lagen, welche keiner Quelle zugeordnet werden konnten. *„\"I can't verify this\" became a first-class result."* **(B) Der Cross-Asset-Widerspruch**: Zwei Assets können jedes für sich korrekt sein, jedes auf eine reale Quelle rückführbar sein, und sich dennoch widersprechen – die Pressemitteilung nennt ein Datum, der Blogbeitrag ein anderes, beide bestehen die Prüfung, das Bundle kann nicht ausgeliefert werden. *„Per-asset verification can't catch that, by construction."* Schlusssatz des Artikels: *„The generation is free. The trust is the product."*

## Titre Article

I built a marketing AI operating system for a 60-person team. The most valuable thing in it is the part that refuses to write.

## Date

2026-08-12

## URL

https://www.linkedin.com/pulse/i-built-marketing-ai-operating-system-60-person-team-most-dumortier-3hbnc

## Keywords

Guillaume Dumortier, Growth Marketing Fit, LinkedIn Pulse, marketing AI OS, KI-Marketing, internes Tool, Claude, Skills, Plugin, Browseranwendung, vier Schichten, Truth-Schicht, Truth-Schicht, Source of Truth, Dokument-Owner, Versionierung, Provenienz, Produktionsschicht, Verifikationsschicht, interne Verteilung, interne Adoption, Trust Machine, Faktendrift, Trennung von Fakten und Content, Skill-Routing, Skill-Abgrenzung, Output-Vertrag, Mehrdeutigkeit, Gliederung statt Artikel, hohle Prüfung, Abnicken, Reinwaschen des Outputs, frische Session, geschlossene Welt, Closed-World, Abdeckungserklärung, Verbot des nackten „pass", nicht verifizierbare Behauptung, vollwertiges Ergebnis, Campaign Bundle, Cross-Asset-Verifikation, Cross-Konsistenz, Widerspruch zwischen Assets, Prüfung, die nie blockiert, zwei Schnittstellen, Adoption folgt Vertrauen, sichtbare Unsicherheit, deterministische Kontrolle, Durchsetzung im Code, Gedankenstrich, asking nicely is not a control, stiller Fehler, geleerte Konstante, Zahlenentfernung, fehlzugeschriebene Halluzination, Pipeline-Test, Validierungslücke, Verweigerung, dem System das Verweigern beibringen, Verifikationsaufwand, Veraltung, Ownership und Provenienz

## Authors

**Guillaume Dumortier** — auteur de la newsletter LinkedIn **Growth Marketing Fit** (~1 300 abonnés à la publication). Il écrit en **praticien-constructeur** : il a passé *« une longue partie de cette année »* à bâtir et exploiter le système décrit. La légende de l'illustration précise le socle technique — *« A custom-built Marketing AI OS within Claude »*. Publié le **12 août 2026**.

## Ton

**Profil**: interner Engineering-Erfahrungsbericht, Ich-Perspektive, veröffentlicht als LinkedIn-Newsletter. Zielgruppe bereits in der Einleitung abgegrenzt: *„This is not a piece about whether AI can write well. If that's still the open question for you, this won't land. It's for people already three months in, quietly wondering why the thing works beautifully in demo and keeps producing outputs nobody trusts enough to ship."* Anti-Demo-Praktiker-Register, trocken, ohne Verkäufer-Vokabular.

**Stil**: Die Struktur ist fest und wird für jede Schicht wiederholt – sechs Überschriften in derselben Reihenfolge, viermal: *What it is* → *Why nobody builds it* → *What I got wrong* → *The rule* → *How you'll know it's working* → *Do this week*. Es ist eine Audit-Vorlage, die sich auf das eigene System anwenden lässt. Erfolgskriterien werden als beobachtbare Signale formuliert statt als Metriken: *„Someone asks \"where did this number come from\" and the answer takes four seconds instead of an archaeological dig through Slack"*, *„people stop asking you which tool to use for what."* Der Text schreibt nie etwas vor, ohne zuvor den entsprechenden Fehler zu schildern, eingestanden in lächerlichem Detail – die Großbuchstaben im Prompt (*„which is roughly the point you should start suspecting you have the wrong model of the problem"*), der Blog-Skill, der Artikel beschrieb statt sie zu schreiben, *„every single time"*, wochenlang. Jeder Abschnitt endet mit einem Aphorismus, was den Text leicht zitierbar macht, auch ohne den zugrunde liegenden Mechanismus. Der Abschnitt *„what I'm still not sure about"* steht vor dem Schluss und wird nicht gescheut, mit Selbstkritik: *„I currently do a mix and I don't think the mix is reasoned, I think it's a tradeoff I haven't properly examined."*

**Charakteristische Formulierungen**:
- ***„I was building a trust machine, and I didn't know it"***
- ***„You cannot demo a truth layer. You can only demo what it prevents, which is nothing visible"***
- ***„Nothing that produces content is allowed to contain a fact. It has to ask"***
- ***„a skill's most important job is describing what it is not for"***
- ***„You do not get a bad review. You get a good review that is worthless"***
- ***„It didn't just miss the error, it certified it"***
- ***„An unverifiable claim is a finding, not a silence"***
- ***„If your review step has never blocked anything, it isn't a review step. It's decoration"***
- ***„adoption tracks trust, not capability"***
- ***„Never ask a model for something you can enforce in code"***
- ***„Traditional software crashes when it breaks. These systems keep going, confidently, at reduced quality"***
- ***„The generation is free. The trust is the product"***

**Epistemische Position**: Praktiker im Betrieb, nicht in der Demonstration. Der Artikel nennt weder das Unternehmen noch die Produkte noch Nutzungszahlen: kein Ergebnis wird gemessen, keine Adoption quantifiziert, kein Vorher/Nachher vorgelegt – was der Autor offen einräumt (*„I'm going to tell you what broke, because the broken parts are the useful part"*). Starke Autorität bei den angetroffenen Fehlermechanismen; keine bei deren Häufigkeit, Kosten oder Allgemeingültigkeit. Zu beachtende Grenzen: n=1, ein einzelner Stack, mehrere vom Autor ohne Nachweis verallgemeinerte Korrekturen, und ein eingeräumter, aber nicht quantifizierter Kostenaufwand.

## Pense-betes

- **Datum / Quelle**: **12. August 2026**, LinkedIn Pulse, Newsletter *Growth Marketing Fit*, ~2.500 Wörter. System gebaut in **Claude** für ein Marketingteam von ~60 Personen.
- **Kern-Framing**: *„I thought I was building a content machine. I was building a trust machine, and I didn't know it, so I spent my initial effort in exactly the wrong place."* ### Das nackte „pass" verbieten Ein Prüfer ist ein **Closed-World-System**: Er kann nur über das urteilen, was ihm vorliegt. Steht er vor einer Behauptung, die keine seiner Quellen abdeckt, findet er keinen Widerspruch und liefert ein positives Urteil, das von einer echten Prüfung nicht zu unterscheiden ist. Die Lösung ist eine Formatvorgabe: | Der Bericht muss angeben | Warum | |---|---| | Wie viele Behauptungen **geprüft** wurden | Nenner: ohne ihn bedeutet ein „OK" nichts | | Wie viele **tatsächlich einer Quelle zugeordnet** werden konnten | das ist die wahre Abdeckungsrate, immer niedriger | | Welche **außerhalb seiner Zuständigkeit lagen** | sonst überschreitet der Prüfer seine Kompetenz, und das Schweigen zu anderen Behauptungen wird als Zustimmung gewertet | | Welche **keiner Quelle im System zugeordnet** sind | das ist das eigentliche Risikoregister der Organisation | *„I can't verify this"* muss ein vollwertiges Ergebnis sein, gleichrangig mit „pass" und „fail". Das symmetrische Antipattern ist gefährlicher als gar keine Prüfung: *„a good review that's worthless is far worse than no review, because it launders the output"* – irgendwo weiter unten in der Kette sieht jemand *reviewed: pass* und schaut nicht mehr genauer hin. Querverweis [[willison-fable-judgement-delegation-subagents-2026-07-03]]. ### Die Prüfung, die eine Verifikation pro Asset nicht leisten kann Zwei Assets derselben Kampagne können jedes für sich korrekt sein, jedes auf eine reale Quelle rückführbar, jedes validiert – und sich dennoch widersprechen. Die Prüfung gegen die Truth-Schicht und die Prüfung von Assets gegeneinander sind **zwei verschiedene Prüfungen**; die erste kann die zweite nicht leisten. Diagnose des Autors: *„if you run multi-asset campaigns and only verify one asset at a time, you have this bug right now."* Übertragung außerhalb des Marketings: ein PR, der drei Dateien betrifft, ein im Batch generierter Satz von Spezifikationen, ein Dokument und der zugehörige Code, gemeinsam erzeugt. Cross-Konsistenz ist eine Prüfung auf Bundle-Ebene, niemals eine Summe von Einzelprüfungen. ### Die Truth-Schicht Geschilderter Fehler: Produktfakten lebten **innerhalb** des Skills, der die Artikel schrieb, dann musste dieselbe Tatsache im E-Mail-Skill, im Battlecard, auf der Webseite existieren. *„Within a few weeks I had four slightly different versions of our launch date in four different files, and the drift was invisible because each file was individually plausible."* Regel: *„a document that states facts and a document that produces content are two different documents, with two different owners"*, jedes versioniert und datiert. Nichts, was Content produziert, darf einen Fakt enthalten – es muss danach fragen. Nutzen: Ändert sich ein Fakt, ändert man ihn einmal, und am nächsten Tag sind alle 35 Skills korrekt; wird eine Behauptung angezweifelt, gibt es nur eine Stelle, an der man nachschauen muss. Warum niemand sie baut: *„You cannot demo a truth layer. You can only demo what it prevents, which is nothing visible."* Vorgeschlagene Übung: die letzten fünf produzierten Assets öffnen, jede faktische Behauptung markieren, für jede das eine Dokument benennen, dem sie gehört – *„the ones you can't assign an owner to are your real risk register."* Erweitert [[vasilopoulos-codified-context-infrastructure-ai-agents-2026-02-24]]. ### Zwei Lektionen über Skills 1. **Der Output-Vertrag muss paranoid gegenüber Mehrdeutigkeit sein.** Wochenlang schrieb der Skill „blog post" **Beschreibungen von Artikeln** – Abschnittsüberschriften, gefolgt von einem Satz, der erklärte, was der Abschnitt behandeln würde, *„every single time"* – und bestand jede Prüfung, weil die Struktur makellos war. Ursache: eine mehrdeutige Zeile im Template (*„the post, under the flavour's own section headers"*), die sich vernünftigerweise als Anfrage nach einer Gliederung lesen ließ. Organisatorisches Detail, wichtiger als der Bug selbst: Niemand meldete es, *„people assume the tool is right and they're using it wrong."* 2. **Die wichtigste Aufgabe eines Skills ist zu beschreiben, wofür er nicht gedacht ist.** Ab etwa dreißig Skills ist das Problem nicht mehr Qualität, sondern wird zum **Routing**: Zwei Skills, die beide plausibel *„write me something for sales"* bearbeiten könnten, konkurrieren um jede Anfrage, und der willkürliche Gewinner produziert das falsche Format. Die Hälfte jeder Beschreibung wurde zu einer expliziten Abgrenzung. Vergleich mit [[shihipar-claude-code-lessons-building-skills-2026-06-03]]. ### Vom Prompt zur Verrohrung Stilregeln verboten Gedankenstriche, jeder Prompt sagte das, Tester fanden sie wochenlang trotzdem: *„I kept repeating the rule louder, which is a probabilistic fix to a problem whose deterministic solution was right there."* Lösung: eine einzige output-seitige Funktion, die sie entfernt. Verallgemeinerbare Heuristik: *„if you catch yourself repeating an instruction, that's the signal to pull it out of the prompt and put it in the plumbing"*, mit ihrem Korollar – *„asking nicely is not a control."* ### Der stille Fehler Eine Konstante, die ein unsichtbares Markierungszeichen halten sollte, war zu einem leeren String geleert worden. Kein sichtbarer Diff, kein Fehler. Weiter unten in der Kette begann ein Bereinigungsschritt, jede Ziffer in jedem Prompt zu erfassen und zu entfernen: `« 7.1% across 6,000+ orgs, 2500 words »` erreichte das Modell als `« .% across ,+ orgs, words »`. Jede Statistik, jedes Datum, jede Wortzahl und jede Abschnittsnummer wurde stillschweigend entfernt, über eine unbekannte Anzahl von Releases hinweg. Das war der eigentliche Grund, warum zitierte Zahlen immer wieder falsch herauskamen – *„and I'd spent weeks blaming the model's tendency to make up numbers. It was making them up because I'd deleted them."* Prinzip: *„Traditional software crashes when it breaks. These systems keep going, confidently, at reduced quality, and produce something that looks correct."* Zwei Korrekturen: **die Pipeline** testen, nicht nur den Output – ein Test, dessen einzige Aufgabe es ist sicherzustellen, dass Zahlen einen Hin-und-Rückweg durch die Prompt-Zusammenstellung überstehen; und sich daran erinnern, dass die eigene Validierung dieselben Lücken hat wie das System – ein auf 500 Zeichen begrenztes Feld blieb über zwei Releases hinweg bei 688 Zeichen, weil das Skript jedes andere Limit prüfte außer dieses eine. Diagnoseregel: Bevor man einem Modell vorwirft, eine Zahl erfunden zu haben, prüfen, ob die Zahl es überhaupt erreicht hat. ### Schicht 4, interne Verteilung *„This is where most internal AI projects die quietly. Not from technical failure. From being technically excellent and used by four people."* Der Autor hatte zunächst für sich selbst gebaut – ein Plugin, das Vertrautheit mit der Kommandozeile voraussetzte, was auf sechs von sechzig Personen zutraf. Lösung: dasselbe System zweimal gebaut, gleiches Wissen und gleiche Prüfungen, zwei Zugangspunkte – ein Plugin für Builder, eine Browseranwendung für alle anderen (Katalog, drei Felder, ein Entwurf mit seinen Prüfungen daneben als Schaltflächen). Der feinste Punkt des Abschnitts: **Adoption folgt Vertrauen, nicht Fähigkeit**. Das Tool wurde stärker genutzt, sobald der Output begann zuzugeben, wobei er sich unsicher war – *„A draft that flags \"this customer example is illustrative, find a real one before publishing\" gets used. A draft that confidently presents a made-up customer example gets used once, embarrasses someone, and the tool dies by word of mouth."* ### Dem System das Verweigern beibringen Der letzte Baustein passt ein Asset für ein anderes Marktsegment an und kennt das Segment, das das Unternehmen beschlossen hat, nicht zu verfolgen: Wird er für dieses Segment angefragt, lehnt er ab und erklärt, warum. *„Same principle as the coverage statement. A system that can only say yes will confidently hand you the wrong thing forever, and you won't be able to tell \"this is right\" from \"this was the only answer available.\""* Verweigerung und das Eingeständnis von Unwissen sind dasselbe Grundprinzip: die Fähigkeit des Systems, den eigenen Kompetenzbereich abzugrenzen. ### Die drei offen gelassenen Unsicherheiten 1. **Eingebettete Truth-Schicht oder Live-Abruf?** *„Embedded copies go stale without anyone noticing. Live fetches are slow and break when someone renames a folder."* Der Autor nutzt eine Mischung und sagt, dass sie nicht durchdacht sei. 2. **Hält der Verifikationsaufwand noch stand?** Ein vollständig geprüftes Asset kostet *„several times"* so viel wie ein Rohentwurf: lohnend für öffentlichkeitswirksame Arbeit, wahrscheinlich nicht für eine interne Zusammenfassung, *„and the line between the two is blurrier than my system claims."* Als Erstes zu instrumentierende Governance-Variable: ein an die Asset-Kritikalität gekoppeltes Verifikationsniveau. 3. **Wie viel davon überlebt die nächsten zwei Modellgenerationen?** Seine als solche präsentierte Wette: Die Truth-Schicht und die Abdeckungsdisziplin überleben, weil sie *„solve an organizational problem of provenance and ownership that would exist even with a perfect model."* ### Der Plan „falls du Montag anfängst" 1. Die **zehn Fakten** notieren, die das Team am häufigsten wiederholt, jeweils mit Owner und Datum – Truth-Schicht Version null, *„it takes an afternoon."* 2. Den besten Prompt nehmen und jeden Fakt daraus in dieses Dokument ziehen; den Prompt danach fragen lassen. 3. Einen Verifikationsschritt bauen, der **in einer frischen Session** läuft, nur den Entwurf und die Quellen sieht und angeben muss, was er nicht prüfen konnte. 4. Herausfinden, was in Prompts immer wieder wiederholt wird, und es in Code verlagern. 5. Es einer nicht-technischen Person zeigen und zusehen, wie sie es ohne Hilfe nutzt. Vor allem anderen durchzuführender Baseline-Test: ein bereits ausgeliefertes Asset in einer komplett frischen Session durch die Prüfung laufen lassen, mit keinem Kontext außer dem Entwurf und den Quellen. *„What comes back is your real quality baseline. It's usually humbling. Mine was."*

## RésuméDe400mots

Erfahrungsbericht, veröffentlicht auf **LinkedIn Pulse** am **12. August 2026** von **Guillaume Dumortier** (Newsletter *Growth Marketing Fit*), über ein internes Marketing-KI-System, gebaut **in Claude** für ein Team von rund sechzig Personen: etwa dreißig Skills, ein Dutzend Truth-Module, **sieben Agenten, von denen sechs nur Arbeit prüfen**, ein Terminal-Plugin, eine Browseranwendung und eine Multi-Asset-Kampagnenorchestrierung.

**Die These.** *„I thought I was building a content machine. I was building a trust machine."* Die Qualität eines KI-Outputs entscheidet sich nicht bei der Generierung, sondern durch **das, was das System vorher weiß**, und **das, was anschließend mit dem Entwurf geschieht**. Die Generierung ist der einfache Teil – und der einzige Teil, den die meisten Teams gebaut haben.

**Vier Schichten.** *Truth*: Faktendokumente, getrennt von allem, was Content produziert, jedes mit einem Owner, versioniert und datiert. Fakten innerhalb der Skills zu belassen erzeugte **vier Versionen eines Launch-Datums in vier Dateien**, jede für sich plausibel. *Production*: Der Blog-Skill verbrachte Wochen damit, **Beschreibungen von Artikeln** statt Artikel zu schreiben, und bestand jede Prüfung, weil die Prüfung die Struktur kontrollierte. Ab dreißig Skills wird das Problem zum **Routing** – die Hälfte jeder Skill-Beschreibung muss angeben, wofür sie nicht gedacht ist. *Verification*: die Schicht, die eine Demo von einem System unterscheidet. *Internal distribution*: wo Projekte daran sterben, exzellent zu sein und von vier Personen genutzt zu werden.

**Die beiden zentralen Fehler.** Ein Fact-Checker erhält eine Behauptung, die keine seiner Quellen abdeckt: Er liefert ein „pass". *„It didn't just miss the error, it certified it."* Lösung: Ein Prüfer ist ein **Closed-World-System**; **es ist ihm untersagt, ein nacktes „pass" zurückzugeben**, und er muss seine Abdeckung offenlegen – wie viele Behauptungen geprüft wurden, wie viele tatsächlich zugeordnet werden konnten, welche außerhalb seiner Zuständigkeit lagen, welche keiner Quelle gehörten. *„An unverifiable claim is a finding, not a silence."* Zweiter Fehler: **Zwei für sich korrekte Assets können sich widersprechen**; die Prüfung pro Asset kann das konstruktionsbedingt nicht erfassen.

**Fünf übergreifende Regeln.** Nie ein Modell um etwas bitten, das sich im Code erzwingen lässt. **Stille Fehler** sind das eigentliche Risiko – eine geleerte Konstante entfernte jede Zahl aus jedem Prompt, und dem Modell wurde Halluzination vorgeworfen. Die Pipeline testen, nicht nur den Output. Die eigene Validierung hat dieselben Lücken wie das System. **Dem System das Verweigern beibringen.**

**Adoption folgt Vertrauen, nicht Fähigkeit**: Ein Output, der zugibt, wobei er sich unsicher ist, wird genutzt. Schlusssatz: ***„The generation is free. The trust is the product."***

## GrapheDeConnaissance

- Guillaume Dumortier —a_créé→ Marketing AI OS (TECHNOLOGIE, 0.96)
- Marketing AI OS —utilise→ Claude (TECHNOLOGIE, 0.93)
- Marketing AI OS —est_instance_de→ système interne à quatre couches — vérité, production, vérification, distribution — servant une équipe marketing d'une soixantaine de personnes avec une trentaine de skills, une douzaine de modules de source de vérité et sept agents dont six ne font que contrôler (AFFIRMATION, 0.94)
- Guillaume Dumortier —affirme_que→ la qualité d'une sortie IA n'est pas déterminée au moment de la génération mais par ce que le système sait avant de commencer et ce qui arrive au brouillon après qu'il a fini (AFFIRMATION, 0.95)
- Guillaume Dumortier —affirme_que→ il croyait construire une machine à contenu alors qu'il construisait une machine à confiance, ce qui lui a fait dépenser son effort initial au mauvais endroit (CITATION, 0.95)
- couche de vérité —fait_partie_de→ Marketing AI OS (TECHNOLOGIE, 0.94)
- couche de vérité —réduit→ la dérive factuelle : un fait modifié une seule fois rend correctes les trente-cinq skills dès le lendemain, et toute affirmation contestée n'a qu'un document propriétaire et qu'une personne à interroger (AFFIRMATION, 0.92)
- Guillaume Dumortier —recommande→ qu'un document qui énonce des faits et un document qui produit du contenu soient deux documents différents avec deux propriétaires différents, rien de ce qui produit du contenu n'ayant le droit de contenir un fait (AFFIRMATION, 0.95)
- vérification en monde clos —s_applique_à→ tout vérificateur automatique adossé à un corpus de sources fini, qui ne peut se prononcer que sur ce qu'on lui a fourni (AFFIRMATION, 0.93)
- vérification en monde clos —observé_dans→ un vérificateur de faits ayant rendu un « pass » sur une affirmation portant sur un produit que ses sources ne couvraient pas : rien ne la contredisait, donc il n'a trouvé aucun problème et a certifié l'erreur au lieu de la manquer (AFFIRMATION, 0.95)
- déclaration de couverture —résout→ la certification en monde clos : le vérificateur ne peut pas renvoyer un « pass » nu et doit énoncer combien d'affirmations il a contrôlées, combien il a réellement appariées à ses sources, lesquelles ne relevaient pas de sa juridiction et lesquelles ne sont possédées par aucune source du système (AFFIRMATION, 0.94)
- Guillaume Dumortier —affirme_que→ une affirmation invérifiable est un constat et non un silence, « je ne peux pas vérifier ceci » devant être un résultat de première classe (CITATION, 0.95)
- Guillaume Dumortier —affirme_que→ une bonne revue sans valeur est bien pire que pas de revue du tout, parce qu'elle blanchit la sortie et que quelqu'un en aval voit « reviewed: pass » et arrête de regarder (AFFIRMATION, 0.94)
- vérification inter-actifs —résout→ la contradiction entre actifs d'un même lot : deux actifs peuvent être individuellement corrects, traçables vers de vraies sources et validés, tout en se contredisant, ce que la vérification par actif ne peut pas attraper par construction (AFFIRMATION, 0.94)
- Guillaume Dumortier —recommande→ que chaque contrôle tourne comme un appel réellement séparé, sans mémoire de la rédaction du brouillon, différents contrôles possédant des juridictions disjointes et n'ayant pas le droit de noter le terrain des autres (AFFIRMATION, 0.93)
- Guillaume Dumortier —affirme_que→ le travail le plus important d'une skill est de décrire ce à quoi elle ne sert pas, le problème cessant d'être la qualité pour devenir le routage passé une trentaine de skills (AFFIRMATION, 0.94)
- ambiguïté du contrat de sortie —observé_dans→ une skill d'article de blog ayant produit pendant des semaines des descriptions d'articles au lieu d'articles, à cause d'une seule ligne ambiguë du gabarit, et passant toutes les revues parce que la revue contrôlait la structure (AFFIRMATION, 0.93)
- Guillaume Dumortier —recommande→ de ne jamais demander à un modèle ce qu'on peut imposer en code, la répétition d'une instruction dans les prompts étant le signal de la déplacer dans la plomberie — demander gentiment n'est pas un contrôle (CITATION, 0.95)
- échec silencieux —observé_dans→ une constante censée contenir un caractère marqueur invisible vidée en chaîne vide, faisant supprimer par une étape de nettoyage chaque chiffre de chaque prompt pendant un nombre indéterminé de releases, sans diff visible ni erreur (AFFIRMATION, 0.95)
- Guillaume Dumortier —affirme_que→ le logiciel traditionnel plante quand il casse alors que ces systèmes continuent avec assurance à qualité réduite et produisent quelque chose qui a l'air correct (CITATION, 0.94)
- Guillaume Dumortier —recommande→ de tester le pipeline et pas seulement la sortie, par exemple un test dont l'unique fonction est d'affirmer que les chiffres survivent à un aller-retour dans l'assemblage du prompt (AFFIRMATION, 0.93)
- Guillaume Dumortier —affirme_que→ l'adoption suit la confiance et non la capacité : un brouillon qui signale son incertitude est utilisé, un brouillon qui présente avec assurance un exemple inventé est utilisé une fois puis l'outil meurt par le bouche-à-oreille (AFFIRMATION, 0.93)
- Guillaume Dumortier —recommande→ de construire la seconde interface plus tôt que ce qui semble justifié et de rendre l'incertitude du système visible plutôt que de la cacher pour paraître plus impressionnant (AFFIRMATION, 0.92)
- Guillaume Dumortier —recommande→ d'apprendre au système à refuser, une étape déclinant explicitement une demande hors périmètre commercial, parce qu'un système qui ne peut que dire oui tendra avec assurance la mauvaise chose sans qu'on puisse distinguer « c'est juste » de « c'était la seule réponse disponible » (AFFIRMATION, 0.94)
- Guillaume Dumortier —affirme_que→ une étape de revue qui n'a jamais rien bloqué n'est pas une étape de revue mais de la décoration (CITATION, 0.94)
- Guillaume Dumortier —mesure→ un actif entièrement vérifié coûte plusieurs fois le prix d'un brouillon brut, ce qui est justifié pour toute publication publique mais probablement pas pour une synthèse interne (MESURE, 0.85)
- Guillaume Dumortier —prédit→ que la couche de vérité et la discipline de couverture survivront aux deux prochaines générations de modèles, parce qu'elles ne compensent pas un raisonnement faible mais résolvent un problème organisationnel de provenance et de propriété qui existerait même avec un modèle parfait (AFFIRMATION, 0.9)
- Guillaume Dumortier —affirme_que→ la génération est gratuite et que la confiance est le produit (CITATION, 0.96)
- déclaration de couverture —s_applique_à→ tout dispositif de LLM-juge hors marketing, notamment la revue de code automatisée et l'évaluation de sorties générées (AFFIRMATION, 0.85)
- Growth Marketing Fit —publie→ Marketing AI OS (TECHNOLOGIE, 0.85)

---
Canonical: https://www.thekb.eu/de/fiches/dumortier-marketing-ai-os-verification-2026-08-12/