AI-Worknote 0.9 — Offene Konvention im Feldtest

ai-worknote.org/0.9: Role: AI-drafted (Claude) / Human: edited / Status: In review / Reviews: Content in progress (C. Blau)

Version 0.9 (Feldtest) · Stand 06.08.2026 · Herausgeber: Carsten Blau, AUFWERT GmbH

Lizenz: CC BY-ND 4.0 — Namensnennung, keine Bearbeitung. Dieser Text darf frei weitergegeben, vervielfältigt und veröffentlicht werden, auch kommerziell, solange der Herausgeber genannt und der Text unverändert übernommen wird. Die Anwendung des Formats ist davon unberührt und uneingeschränkt frei — sie erfordert keine Erlaubnis, keine Registrierung und keine Nennung. Bearbeitungen und Übersetzungen auf Anfrage. Einzelheiten in Abschnitt 10.3.

Worum es geht — in Kürze

Das Problem: In Organisationen entstehen Texte heute im Mix aus mehreren KI-Systemen (Copilot, ChatGPT, Claude, Gemini …) und menschlicher Arbeit — und wandern per Copy-Paste durch Word, E-Mail, Wiki und Präsentationen. Spätestens nach dem ersten Kopieren sieht niemand mehr: Ist das ein KI-Entwurf? Wurde er geprüft? Ist er freigegeben? Systemmetadaten überleben diese Wege nicht, und ein durchgängiges Redaktionssystem, das den Status führt, gibt es in den meisten Organisationen nicht.

Die Lösung: Die AI-Worknote ist eine Zeile im Text selbst, die genau diese drei Fragen beantwortet — und mit dem Inhalt reist, egal wohin er kopiert wird:

ai-worknote.org/0.9: Role: AI-drafted (M365 Copilot) / Human: - / Status: Draft / Reviews: -

Fast ohne Aufwand: Die KI schreibt die Zeile selbst — ein kurzer Systemprompt-Abschnitt genügt (Abschnitt 3.6), dann setzen Copilot, ChatGPT, Claude oder Gemini sie bei jeder Ausgabe automatisch. Pflegen heißt: bei Statuswechsel ein Wort ändern. Kein neues Werkzeug, kein Login, keine Metadaten-Pflicht.

Die Positionierung: Die AI-Worknote ist eine leichtgewichtige, pragmatische offene Konvention für interne Status-Transparenz — bewusst kein Provenienz-Standard, keine Signatur, kein Compliance-Nachweis (Abschnitt 1.6). Sie füllt die Lücke zwischen den Systemen: dort, wo Inhalte entstehen und wandern, bevor sie in gelenkten Ablagen ankommen.

Hinweis: Nicht jeder Inhalt braucht eine Worknote. Sie lohnt sich bei Inhalten, die aufbewahrt, freigegeben oder veröffentlicht werden — nicht bei flüchtiger, direkt geprüfter Kommunikation wie einer kurz gegengelesenen Antwort-Mail (Abschnitt 1.5).

Darüber hinaus gilt:

• Gerade dort, wo Entwürfe von der KI stammen, zahlt sich die Kennzeichnung aus: Jeder sieht sofort, dass ein Text als KI-Entwurf begann und ob er seitdem geprüft wurde — die Information, die sonst als Erste verloren geht.
• Ein einfaches Sicherheitsprinzip: Eine vergessene Worknote überzeichnet den KI-Anteil, sie untertreibt ihn nie (Asymmetrie-Prinzip, Abschnitt 5.1). Nachlässigkeit führt zu Vorsicht, nicht zu verdecktem KI-Einsatz.
• KI-Agenten im Workflow sind berücksichtigt: Agentische Systeme werden wie jedes andere KI-System erfasst (Abschnitte 3.1, 9.2).
• Externe Kennzeichnungen sind berücksichtigt: Das Feld Labels: dokumentiert Kennzeichnungen für Veröffentlichungen, etwa nach dem EU AI Act (Abschnitt 4.2, Kapitel 8).
• Auch für Inhalte ohne KI sinnvoll: Role: None dokumentiert den rein menschlichen Ursprung — und liefert den Ausgangspunkt, falls der Text später von KI bearbeitet wird.
• Wer sie nicht kennt, gibt die Adresse im Browser ein und findet die Erklärung.

Die Feldnamen und Werte sind bewusst englisch gehalten, damit die Worknote über Sprach- und Werkzeuggrenzen hinweg einheitlich bleibt. Für verschiedene Sprachen ist begleitende Unterstützung (Erläuterungen, Hilfetexte) vorgesehen.

Was Sie lesen sollten

Für den Einstieg genügt ein Handgriff: Fügen Sie den Prompt-Abschnitt aus 3.6 in den Systemprompt Ihres KI-Chatbots ein — je nach Produkt heißt das Feld „Anweisungen”, „Custom Instructions” oder „Systemprompt”. Danach setzt die KI die Worknote selbst; Abschnitt 3.5 zeigt, was Sie im Alltag daran ändern.

Die Kapitel 6 bis 9 und Anhang B richten sich an Umsetzende und sind für die tägliche Anwendung nicht erforderlich.

TEIL A — ESSENTIALS

Dieser Teil genügt für die tägliche Anwendung: Worum es geht, die Zeile, die drei Dimensionen, der Schnellstart-Prompt. Er ist so gehalten, dass er auf ein Cheat-Sheet passt.

1. Zweck und Szenario

1.1 Problem

In Organisationen entstehen Texte zunehmend im Zusammenspiel von Menschen und KI. Wer einen Text liest, weiterverwendet, freigibt oder veröffentlicht, sieht ihm nicht an, welchen Anteil KI daran hatte, wie weit er gediehen ist und ob ihn jemand geprüft hat. Genau das brauchen aber alle, die mit dem Text weiterarbeiten: für die Qualitätssicherung, für Freigaben und für die Frage, ob eine Veröffentlichung gekennzeichnet werden muss.

Die AI-Worknote beantwortet diese drei Fragen mit einem kurzen Vermerk im Text selbst.

Warum das vorher nicht nötig war: Früher war der Autor die Provenienz — ein Text hatte einen Verfasser, und wer ihn erhielt, wusste, wen er fragen kann. KI hat diese Kopplung zerschnitten: Der Text hat keinen Verfasser mehr, das Volumen ist um Größenordnungen gestiegen, und die Formulierungsqualität sagt nichts mehr über die Sorgfalt — der ungeprüfte Entwurf klingt so souverän wie das freigegebene Dokument.

1.2 Zwei-Ebenen-Modell

Der Standard unterscheidet strikt zwischen zwei Kennzeichnungsebenen:

Die Worknote ist nie selbst das externe Label. Sie liefert die Grundlage, aus der ein Redakteur oder ein Publikationsprozess das externe Label ableitet (Kapitel 8) und dokumentiert das Ergebnis im Feld Labels: (Abschnitt 4.2).

1.3 Rahmenbedingungen

Die Konvention ist bewusst für Organisationen entworfen, in denen gilt:

• Kein durchgängiges Redaktionssystem. Es gibt kein DMS oder CMS, das Status, Prüfungen und Kennzeichnungen über den gesamten Prozess End-to-End führt.
• Systemagnostik. Die Information muss über Werkzeug- und Organisationsgrenzen hinweg erhalten bleiben. Deshalb ist sie Bestandteil des Inhalts und nicht Metadatum eines Systems.
• Keine neuen Systeme. Die Anwendung setzt keine zusätzliche Software, Infrastruktur oder Signaturverfahren voraus.

Diese Bedingungen erklären Stärken und Grenzen des Ansatzes: Die Worknote reist mit dem Inhalt, ist aber Freitext und damit weder erzwingbar noch fälschungssicher. Kapitel 5 beschreibt die Prinzipien, mit denen der Standard damit umgeht.

1.4 Geltungsbereich

Anwendbar auf alle Textformate, insbesondere:

• Textdokumente (Word, PDF, OpenDocument)
• Präsentationen und Tabellen
• Wiki-, Intranet- und Portalseiten
• E-Mails und Chat-Nachrichten
• Markdown und einfache Textdateien

Nicht empfohlen für Quellcode in einer Versionsverwaltung. Dort bilden Commit-Angaben (Co-Authored-By:, Generated-By:), die Änderungshistorie und Freigaben in Pull Requests dieselbe Information genauer und aktueller ab. Die Worknote kommt im Code nur dort in Betracht, wo keine Versionsverwaltung im Einsatz ist — etwa bei einzeln verteilten Skripten, Makros oder Konfigurationsdateien.

1.5 Wann eine Worknote sinnvoll ist

Die Konvention ist nicht dafür gedacht, jeden Inhalt zu kennzeichnen. Neuere Transparenz-Rahmenwerke folgen einem risiko- und relevanzbasierten Ansatz und vermeiden bewusst flächendeckendes Labeling: Gekennzeichnet wird, wo es einen Zweck erfüllt — nicht pauschal.

Leitfrage: Wird jemand später den Entstehungszustand kennen wollen? Das ist bei Inhalten der Fall, die aufbewahrt, weitergegeben, freigegeben oder veröffentlicht werden.

Worknote sinnvoll: - Dokumente mit Bestand: Berichte, Konzepte, Angebote, Verträge, Richtlinien, Wissensartikel - Inhalte, die in Freigabe, Veröffentlichung oder eine Wissensbasis laufen - Inhalte, deren Verlässlichkeit oder Herkunft später jemand einschätzen muss

Worknote entbehrlich: - flüchtige Kommunikation: kurze Chats, Routine-Antwortmails, die ein Mensch prüft und sofort versendet - rein persönliche Notizen und Entwürfe für den Eigengebrauch - Inhalte unterhalb der Kennzeichnungsschwelle (nur Rechtschreib-/Grammatikhilfe, Abschnitt 3.1)

Regel zum Weglassen — zwei Bedingungen gemeinsam: Die Worknote darf entfallen, wenn (1) ein Mensch den Inhalt gelesen oder geprüft hat und (2) der Inhalt nicht als Referenz oder Autorität aufbewahrt wird.

• Die geprüfte Routine-Mail erfüllt beides und braucht keine Worknote — das deckt sich mit der EU-AI-Act-Logik, nach der menschlich geprüfte Inhalte mit redaktioneller Verantwortung von der externen Kennzeichnung ausgenommen sind.

• Ein geprüfter, aber aufbewahrter Bericht erfüllt nur Bedingung (1): Hier bleibt die Worknote, und die Prüfung wird in ihr festgehalten.

Bei aufbewahrten Dokumenten ist die Nennung des KI-Beitrags zudem schlicht fair — wie die Nennung eines Mitwirkenden. Die Worknote nennt den Beitrag; Autorenschaft und Verantwortung bleiben beim Menschen.

Im Zweifel: kennzeichnen. Eine fehlende Worknote an flüchtigem Inhalt ist kein Verstoß (5.4).

Detailtiefe nach Bedarf. Wie ausführlich dokumentiert wird, hängt von Organisation und Verwendungszweck ab: Für interne Nachvollziehbarkeit genügt das Kernprofil (Role / Status / Reviews); in regulierten oder nachweispflichtigen Kontexten kommen Personenangaben, AI checks: und AI history: hinzu. Die Konvention gibt den Rahmen vor, nicht das Pflichtniveau.

1.6 Was die AI-Worknote nicht ist

Die AI-Worknote ist eine Selbstauskunft im Text — leichtgewichtig und pragmatisch, mit bewussten Grenzen:

• Kein Provenienz-Beweis: Sie ist Freitext ohne Signatur oder Integritätsschutz. Sie kann irrtümlich oder absichtlich falsch gesetzt werden. Für fälschungssichere Herkunftsnachweise existieren Standards wie C2PA/Content Credentials; die Worknote ersetzt sie nicht, sondern kann als menschenlesbare Ergänzung neben ihnen bestehen.
• Kein Compliance-Nachweis: Sie ist weder eine maschinenlesbare Anbietermarkierung noch ein externes Label im Sinne des EU AI Act. Sie liefert interne Informationen, aus denen eine separate Kennzeichnungsentscheidung abgeleitet werden kann (Kapitel 8) — nicht mehr.
• Kein Ersatz für Dokumentenlenkung: Wo ein DMS/CMS mit Pflichtmetadaten, Freigabe-Workflows und Audit-Trail konsequent genutzt wird, ist es das führende System. Die Worknote füllt die Lücke davor und dazwischen: Inhalte entstehen in Chatbots und Copilot-Oberflächen, die keine DMS-Attribute schreiben, und wandern per Copy-Paste durch Werkzeuge, bevor sie in einer gelenkten Ablage ankommen. Die Worknote ist der Transportweg für den Status auf dieser Strecke — und kann bei Ankunft im DMS in dessen Metadaten übernommen werden.
• Kein Ersatz für technische Ansätze an der Quelle: Eigene technische Lösungen würden dasselbe Problem robuster lösen, weil sie nicht auf Disziplin angewiesen sind. Sie setzen aber eigene Infrastruktur, Budget und Kontrolle über alle beteiligten Systeme voraus. Die Konvention ist die organisatorische Antwort für Umgebungen ohne diese Voraussetzungen — und bleibt daneben anschlussfähig.
• Keine Qualitätsaussage: done und Approved dokumentieren, dass geprüft und freigegeben wurde — nicht, dass der Inhalt fehlerfrei ist.

Wer darf was setzen (Autoritätsmodell): Die Felder haben unterschiedliche Verbindlichkeit, weil sie von unterschiedlichen Stellen stammen:

Ein KI-System darf ausschließlich Role: (und die Defaults Status: Draft / Reviews: -) setzen — nie Prüfbestätigungen, Freigaben oder Labels.

2. Kurzübersicht

2.1 Syntax

ai-worknote.org/0.9: Role: <Wert> / Human: <Wert> / Status: <Wert> / Reviews: <Wert>

Optional erweiterbar um AI checks:, Labels: und AI history:.

Kernprofil und Erweiterungen: Für den Feldtest verbindlich ist nur das Kernprofil Role / Human / Status / Reviews. Die optionalen Felder (Kapitel 4) sowie Abschnittsgeltung (Kapitel 6), Konsumregeln (Kapitel 7) und Agentenprofile (9.2) sind experimentelle Erweiterungen — nützlich, aber im Feldtest ausdrücklich zur Erprobung gestellt. Feldtrenner ist /, mehrere Einträge innerhalb eines Feldes werden durch ; getrennt, Parameter in Klammern durch ,.

2.2 Beispiel

ai-worknote.org/0.9: Role: AI-drafted (M365 Copilot) / Human: edited / Status: In review / Reviews: Editorial done (Jane Doe, 24.07.2026); Legal open

2.3 Felder auf einen Blick

3. Die Pflichtfelder

3.1 Role — materieller KI-Anteil

Merksatz: Role: beschreibt immer, was die KI getan hat — nie, was der Mensch getan hat.

Die Stufennummer definiert die Rangfolge: Wo diese Spezifikation von der „höheren” oder „höchsten” Stufe spricht, ist die höhere Nummer gemeint (AI-drafted = höchste Stufe).

Kennzeichnungsschwelle. Rein mechanische Hilfe gilt als None und wird nicht gekennzeichnet: Rechtschreibung, Grammatik, Autovervollständigung, Silbentrennung — auch wenn unklar ist, ob KI oder klassischer Algorithmus dahintersteckt. AI-assisted beginnt erst bei inhaltlicher Zuarbeit (Recherche, Ideen, Struktur).

Abgrenzungshilfe AI-drafted vs. AI-revised vs. AI-assisted. Maßgeblich ist nicht ein Mengenanteil, sondern wer den Text formuliert hat — ein Ursprungstest in zwei Fragen:

1. Hat die KI den Text (oder wesentliche Passagen davon) geschrieben? → AI-drafted. Das gilt auch, wenn der Mensch danach viel geändert hat (Gesamtwert-Prinzip); die menschliche Bearbeitung wird im Feld Human: ausgedrückt, nicht durch eine niedrigere Stufe.
2. Stammt der Text vom Menschen, und die KI hat ihn umgearbeitet? → AI-revised. Hat die KI nur zugearbeitet, ohne zu formulieren → AI-assisted.

Auf eine Prozent-Schwelle („ab x % KI-Anteil”) verzichtet die Konvention bewusst: nicht messbar (Prozent wovon?), lädt zum Schönrechnen ein — und etablierte Regelwerke (Open-Source-Richtlinien, US Copyright Office) unterscheiden ebenfalls nach Mechanismus bzw. kreativer Kontrolle, nicht nach Mengenanteilen.

Sonderfall Übersetzung. KI übersetzt menschlichen Text → AI-revised, empfohlen mit Zusatz translated: Role: AI-revised (Claude, translated) (eigenes Fehlerrisiko sichtbar machen). Kein eigener Role-Wert — die vierstufige Skala bleibt einfach. Einzelne Wörter/Wendungen: unterhalb der Kennzeichnungsschwelle.

Gesamtwert-Prinzip. Role: bezeichnet den Zustand der aktuellen Fassung, nicht die Entstehungshistorie. Es gibt genau einen Wert, keine Kette.

Zentrale Regel: Bearbeitet ein Mensch einen KI-Entwurf, bleibt der Wert AI-drafted. Er wird dadurch nicht zu AI-revised — denn AI-revised beschreibt, dass die KI menschlichen Text überarbeitet hat, also den umgekehrten Fall. Eine Herabstufung erfolgt ausschließlich durch bewusste menschliche Entscheidung (Abschnitt 5.3).

Die menschliche Bearbeitung eines KI-Entwurfs wird nicht in Role: vermerkt, sondern im eigenen Feld Human: (Abschnitt 3.2). Grund: Jedes Feld dieser Konvention beschreibt genau einen Akteur — Role: und AI checks: die KI, Human:, Reviews: und Labels: den Menschen.

Systemangabe. In Klammern wird das verwendete System genannt: AI-drafted (M365 Copilot), AI-revised (ChatGPT Enterprise), AI-drafted (Claude Cowork). Agentische Systeme werden wie jedes andere System behandelt; sie bilden keine eigene Beitragsklasse.

Keine Modell- oder Versionsangabe. Der Produktname genügt. Modell- und Versionsangaben werden bewusst nicht verlangt: KI-Systeme kennen ihre eigene Version nicht zuverlässig und erzeugen auf Nachfrage plausible, aber falsche Angaben — und Produktversionen unterscheiden sich je nach Tenant und Rollout-Welle. Wo der Zeitpunkt zählt, gehört er als Datum in AI history: (z. B. 2026-08-02 AI-drafted (M365 Copilot)), nicht in den Systemnamen. Kennt ein Mensch die Modellangabe sicher, darf er sie ergänzen ((ChatGPT, GPT-5.2)) — die KI setzt sie nie selbst.

Bei Unsicherheit gilt die höhere Stufe. Wer nicht beurteilen kann, ob ein eingefügter Text menschlichen oder KI-Ursprungs ist, wählt den Wert mit der höheren Stufennummer.

3.2 Human — menschlicher Beitrag

Ergänzt Role: um die Gegenfrage: Was hat ein Mensch zu dieser Fassung beigetragen?

Beide Werte können zusammen auftreten: Human: directed, edited.

Warum directed: Die verbreitetste Form menschlicher Mitwirkung ist heute nicht das Umschreiben von Text, sondern das Führen über mehrere Runden. Ohne diesen Wert trägt ein über Dutzende Iterationen gesteuertes Dokument dieselbe Worknote wie eine ungelesene Ein-Prompt-Ausgabe.

Schwelle für directed: Mehrere Runden mit substanziellen Richtungsentscheidungen — eigene Inhalte, verworfene Vorschläge, bewusste Auswahl. Ein einzelner Prompt mit Nachbesserung genügt nicht; das ist normale Nutzung und bleibt -.

Das Feld wird von KI-Systemen mit - vorbelegt und nur vom Menschen auf directed bzw. edited gesetzt. Damit bleibt die Pflege ein Wortwechsel, und die Angabe steht schon da, statt später ergänzt werden zu müssen.

Abgrenzung zu Reviews:: Human: beschreibt Mitwirkung an der Entstehung, Reviews: beschreibt Prüfung. Wer führt oder umschreibt, hat damit nicht geprüft. Reviews: bleibt das härtere Vertrauenssignal — Human: ist Selbstauskunft ohne Prüfcharakter und sollte nie als Ersatz dafür gelesen werden.

Schwelle für edited: Wie bei Role: zählt nur substanzielle Arbeit. Tippfehler, Formatierung und Layout sind keine Bearbeitung im Sinne dieses Feldes.

Nicht anwendbar bei Role: None — dort ist der menschliche Ursprung bereits durch None ausgedrückt; das Feld entfällt.

3.3 Status — Stand im Bearbeitungsprozess

Diese Dimension entspricht der klassischen Dokumentenlenkung (u. a. ISO 9001, Abschnitt 7.5) und ist bewusst vertraut gehalten.

Optionale Werte für Veröffentlichungsprozesse: For publication, Scheduled (mit Zeitangabe, z. B. Scheduled (25.07.2026, 08:00)), Published, Archived, Withdrawn, Rejected.

Approved erfordert eine tatsächliche Freigabeentscheidung durch eine dazu befugte Person. Abgeschlossene Reviews allein begründen keine Freigabe.

Invalidierung bei materieller Änderung. Nach Prüfung/Freigabe materiell geändert → Status: zurück auf Draft/In review, betroffene Reviews auf open. Ein fortbestehendes Legal done an einer veränderten Fassung ist das gefährlichste Fehlerbild dieser Konvention. Frühere Freigaben bei Bedarf in AI history:/Freigabeprotokoll; Tippfehlerkorrekturen lösen keine Invalidierung aus.

3.4 Reviews — menschliche Prüfungen

Reviews: <Art> <Zustand> [(<Person>[, <Datum>])]

• Art (offene Liste): Editorial, Factual, Technical, Legal, Compliance, Final — kann nach eigenem Ermessen um weitere Reviewarten ergänzt werden
• Zustand: open · in progress · done
• Mehrere Reviews werden durch ; getrennt.
• Reviews: - bedeutet: keine menschliche Prüfung erfolgt. Das ist der Default.

Beispiel: Reviews: Editorial done (Jane Doe, 24.07.2026); Legal in progress (Legal)

done bezeichnet den Bearbeitungsfortschritt, nicht die Fehlerfreiheit. Ein abgeschlossenes Review sagt aus, dass eine Prüfung stattgefunden hat — nicht, dass der Inhalt korrekt ist.

Personenangabe — Stufenkatalog. Zulässig sind:

Personenangaben verlassen mit dem Inhalt die Organisation — deshalb ist die Funktions-/Rollenangabe der Default und der Klarname die begründungsbedürftige Ausnahme. Wer Klarnamen verwendet, sollte die datenschutzrechtliche Grundlage (regelmäßig berechtigtes Interesse) und die Informationspflichten gegenüber den Betroffenen berücksichtigen. Bei Veröffentlichung wird die Worknote ohnehin entfernt (Abschnitt 5.8).

3.5 Was ändere ich wann? — Kurzanleitung

Die häufigsten Situationen und der jeweils nötige Handgriff. Mehr braucht der Alltag nicht.

Faustregel bei Unsicherheit: Lieber stehen lassen als raten. Eine unveränderte Worknote überzeichnet höchstens den KI-Anteil — das ist die sichere Richtung (5.1). Falsch wäre nur, eine Prüfung oder Freigabe einzutragen, die nicht stattgefunden hat.

3.6 Schnellstart: der Systemprompt (Kurzfassung)

In die Systemanweisungen des Chatbots einfügen — mehr braucht es für den Start nicht. Das Format kommt bewusst ohne Sonderzeichen aus: Manche Oberflächen (beobachtet bei Gemini) blockieren gespeicherte Anweisungen mit eckigen Klammern als vermeintliches Injection-Muster.

=== AI-WORKNOTE (KURZ) ===
Beginne jede Textausgabe mit:
ai-worknote.org/0.9: Role: <Wert> (<System>) / Human: - / Status: Draft / Reviews: -
<System> = dein Produktname.

Role = dein Beitrag:
AI-drafted (Text von dir) | AI-revised (menschlichen Text umgearbeitet;
Übersetzung: <System>, translated) | AI-assisted (nur Zuarbeit) | None
Reine Rechtschreib-, Grammatik- oder Formathilfe: keine Kopfzeile.

Human, Status, Reviews und Labels setzt nur der Mensch. Gib immer die
Startwerte aus, ändere vorhandene Angaben nie, erfinde keine Werte.
Ein KI-Entwurf bleibt AI-drafted. Unklare Herkunft: höhere Stufe.
Nie herabstufen. Fremde Worknotes nie entfernen.
"ohne worknote": Kopfzeile weglassen, bis "mit worknote" folgt.
Fragen zu Werten oder Bedeutung: unter ai-worknote.org/0.9 nachschlagen,
falls du Webzugriff hast - sonst dorthin verweisen statt zu raten.

TEIL B — VERTIEFUNG UND ERWEITERUNGEN (bei Bedarf)

Optionale Felder, Lebenszyklusregeln, Mehrfachvorkommen, Konsumregeln, externe Labels, weitere Prompts und Umsetzung. Für den Einstieg nicht erforderlich.

4. Optionale Felder

4.1 AI checks — KI-gestützte Prüfungen

Gleiche Grammatik wie Reviews:, jedoch strikt getrennt davon. KI-gestützte Prüfungen ersetzen keine menschlichen Reviews und dürfen nie in das Feld Reviews: eingetragen werden.

AI checks: Factuality done (Claude); Compliance done (M365 Copilot)

4.2 Labels — externe Kennzeichnungen

Dokumentiert, welche Kennzeichnungen für die veröffentlichte Fassung entschieden bzw. angebracht sind. Das Feld ist nicht an ein bestimmtes Regelwerk gebunden: EU-Vorgaben, Plattform-Deklarationen, Kundenauflagen und interne Vorgaben werden mit derselben Syntax abgedeckt; das jeweilige Regelwerk wird in Klammern genannt.

Konventionen:

• Anführungszeichen kennzeichnen den wörtlichen externen Labeltext und grenzen ihn von Metaangaben ab.
• documented ist ein definiertes Kurzwort: Die Grundlage der Entscheidung (Prüfung, redaktionelle Verantwortung, Bewertung) ist außerhalb der Worknote nachgewiesen.
• Labels: darf ausschließlich von einem Menschen oder einem autorisierten Publikationsworkflow gesetzt werden, nie von einem KI-System auf eigene Initiative.
• Empfohlene Form für Auditfähigkeit: Person und Datum ergänzen, z. B. Labels: none (EU CoP, human review documented, Jane Doe, 24.07.2026).

4.3 AI history — optionale Entstehungskette

Für Nachweisfälle, in denen die Historie dokumentiert werden soll:

AI history: 2026-07-20 AI-drafted (M365 Copilot); 2026-07-22 AI-revised (Claude Cowork)

Das Feld ersetzt nicht Role: — der Gesamtwert bleibt maßgeblich.

Wer es setzt: Menschen oder agentische Systeme mit verlässlichem Datumsbezug. Chatbots führen AI history: nicht standardmäßig — ein einzelner Eintrag wiederholte nur Role:, und Datumsangaben aus dem Modell sind nicht zuverlässig. Deshalb ist das Feld in den Standard-Systemprompts (3.6, 9.1) nicht enthalten, sondern nur im Agentenprofil (9.2).

5. Grundprinzipien und Lebenszyklus

5.1 Asymmetrie-Prinzip

Eine nicht gepflegte Worknote überzeichnet den KI-Anteil, sie untertreibt ihn nie. Das ist beabsichtigt und hat zwei Wirkungen: Der Fehlerfall liegt auf der sicheren Seite (Überkennzeichnung ist unschädlich, Unterkennzeichnung nicht), und wer seinen menschlichen Anteil sichtbar machen will, hat einen Anlass, die Worknote aktiv nachzuführen.

5.2 Streng schreiben, tolerant lesen

Beim Schreiben gilt die kanonische Form (Anhang B): definierte Werte, definierte Trenner, definierte Reihenfolge.

Beim Lesen wird Abweichung toleriert. Auszuwerten sind auch Worknotes mit:

• abweichender Groß- und Kleinschreibung der Feldnamen
• https:// oder www. vor der Referenz-URL oder abschließendem Schrägstrich
• zusätzlichen Leerzeichen oder Komma statt Semikolon als Trenner
• mehrzeiliger Darstellung
• Tippfehlern in Werten, soweit eindeutig zuordenbar

Nicht interpretierbare Bestandteile werden ignoriert und nicht als Fehler behandelt.

5.3 Nie herabstufen, nie fremde Worknotes entfernen

• Ein KI-System darf Role: hochstufen, wenn sein Beitrag das rechtfertigt, aber nie herabstufen.
• Ein KI-System darf keine Reviews, Freigaben, Personen oder Labels erfinden.
• Ein KI-System darf bestehende Worknotes anderer Abschnitte weder löschen noch verschmelzen. Konsolidierung ist eine menschliche Entscheidung (Abschnitt 6.4); auf ausdrückliche Anweisung darf ein System sie ausführen und wendet dabei die Auswertungsregel an.
• Eine Herabstufung durch einen Menschen ist zulässig, sollte aber eine bewusste, begründbare Entscheidung sein. Empfohlen ist ein Kurzvermerk, z. B. Role: AI-assisted (downgraded: vollständig neu verfasst).

5.4 Fehlende Worknote bedeutet keine Aussage

Das Fehlen einer Worknote ist nicht gleichbedeutend mit Role: None. Es bedeutet: keine Aussage. Diese Regel ist Voraussetzung dafür, dass die Konvention schrittweise eingeführt werden kann, ohne Bestandsinhalte falsch zu klassifizieren. Gleiches gilt für ein fehlendes Human:-Feld und für fehlende optionale Felder.

5.4a Weglassen und Entfernen bei flüchtigen Inhalten

Bei flüchtigen Inhalten (1.5: geprüft, nicht als Referenz aufbewahrt) darf die Worknote weggelassen oder ersatzlos entfernt werden — auch wenn ein Systemprompt sie automatisch gesetzt hat. Die einzige konsequenzlose Entfernung; Merksatz zu 5.3: Weglassen ist erlaubt, Verfälschen nicht.

5.5 Verantwortung für die Pflege

Die Person, die einen Inhalt materiell zuletzt geändert hat, verantwortet die Aktualität der Worknote. Bei gemeinsamer Bearbeitung sollte die Verantwortung im Team benannt werden; andernfalls verfällt die Worknote am schnellsten.

5.6 Einfügen und Zusammenführen

Wird gekennzeichneter Inhalt in ein gekennzeichnetes Dokument eingefügt, gilt:

• Die Dokument-Worknote bleibt maßgeblich; ihr Role:-Wert wird bei Bedarf hochgestuft, nie herabgestuft.
• Die eingefügte Worknote darf als Segment-Worknote erhalten bleiben (Kapitel 6) oder beim Konsolidieren entfernt werden.
• Status: und Reviews: des eingefügten Inhalts werden nicht übernommen.

5.7 Weiterverarbeitung und Vererbung

Werden aus vorhandenen Inhalten neue Artefakte erzeugt (Zusammenfassungen, SOPs, Skills, Schulungsunterlagen), gilt für das Ergebnis:

• Role: = höchste Stufe aller Quellen, mindestens jedoch der eigene Beitrag des erzeugenden Systems
• Status: = Draft
• Reviews: = -
• AI checks: = entfällt (Prüfungen der Quellen gelten nicht für das neue Artefakt)
• Labels: = -
• AI history: = optional neu begonnen; Einträge der Quellen werden nicht übernommen

5.8 Veröffentlichung

Vor der Veröffentlichung an Externe wird die Worknote aus der zu veröffentlichenden Fassung entfernt — sie enthält interne Prozessinformationen und ggf. Personennamen. An ihre Stelle tritt, falls erforderlich, das externe Label (Kapitel 8).

Der letzte interne Stand mit Worknote ist aufzubewahren, damit die Kennzeichnungsentscheidung nachweisbar bleibt. Beides ist zulässig und sollte organisationsweit einheitlich geregelt werden:

1. Der finale interne Stand verbleibt mit Worknote in der regulären Ablage; veröffentlicht wird eine Ausleitung ohne Worknote.
2. Die Worknote wird zusätzlich in das Freigabeprotokoll, Ticket oder Publikationsvermerk übertragen.

5.9 Typische Workflow-Übergänge (ausformuliert)

Die folgenden Übergänge beschreiben den Normalverlauf so, dass Menschen und KI-Systeme unmittelbar damit arbeiten können. Jeder Übergang nennt Auslöser und Worknote-Änderung.

T1 — Erzeugung im Chatbot. Die KI erstellt eine Textausgabe. → Sie schreibt die Kopfzeile mit dem zutreffenden Role:-Wert, Status: Draft, Reviews: -.

T2 — Übernahme in ein Zieldokument. Ein Mensch fügt die Ausgabe in ein Dokument ein. → Die Dokument-Worknote ist maßgeblich; ihr Role:-Wert wird bei Bedarf hochgestuft, nie herabgestuft. Die eingefügte Worknote bleibt als Segment-Worknote stehen oder wird beim Konsolidieren entfernt (6.4).

T3 — Menschliche Bearbeitung eines KI-Entwurfs. Ein Mensch überarbeitet den Text. → Role: bleibt AI-drafted; Human: wechselt von - auf edited.

T4 — Prüfung beginnt. Eine Person startet ein Review. → Status: In review; Reviews: <Art> in progress (<Person>).

T5 — Prüfung abgeschlossen. Die prüfende Person schließt ab. → Reviews: <Art> done (<Person>, <Datum>). done setzt nur die prüfende Person selbst.

T6 — Freigabe. Eine befugte Person gibt frei. → Status: Approved. Voraussetzung: eine eindeutige Dokument-Worknote (6.2).

T7 — Materielle Änderung nach Prüfung oder Freigabe. Der Inhalt wird inhaltlich geändert. → Invalidierung (3.2): Status: zurück auf Draft bzw. In review, betroffene Reviews auf open. Reine Tippfehlerkorrekturen lösen T7 nicht aus.

T8 — Veröffentlichung. Der Inhalt geht an Externe. → Kennzeichnungsentscheidung treffen und in Labels: dokumentieren (Kapitel 8); Worknote aus der veröffentlichten Fassung entfernen; letzten Stand mit Worknote aufbewahren (5.8).

T9 — Übernahme in Wissensbasis oder SOP. Der Inhalt wird Referenzmaterial. → Nur bei Status: Approved und mindestens einem abgeschlossenen Review übernehmen (K3/K4); Worknote als Metadatum vererben; für abgeleitete Artefakte gilt 5.7.

T10 — Flüchtiger Inhalt. Der Inhalt wurde geprüft, versendet und wird nicht aufbewahrt. → Die Worknote darf entfallen oder entfernt werden (5.4a); keine weitere Pflege nötig.

6. Geltungsbereich, Mehrfachvorkommen und Konsolidierung

Dokumente werden regelmäßig aus mehreren KI-Antworten zusammengesetzt — etwa beim Anhängen von Antworten an eine Seite oder beim Einfügen aus verschiedenen Chatbots. Da ein KI-System nicht wissen kann, ob seine Antwort übernommen wird, sind mehrere Worknotes in einem Dokument ein Normalzustand und kein Fehler.

6.1 Geltungsregel

Eine Worknote gilt ab ihrer Position bis zum Ende der Struktureinheit, in der sie steht — endet aber vorzeitig, sobald eine weitere Worknote auf gleicher oder höherer Ebene erscheint.

• Steht sie am Dokumentanfang oder unmittelbar unter dem Titel, ist die Struktureinheit das Dokument.
• Steht sie unmittelbar nach einer Überschrift, ist die Struktureinheit der Abschnitt einschließlich seiner Unterabschnitte.
• Steht sie im laufenden Text ohne Überschriftenbezug (typisch bei zusammengesetzten Seiten), gilt sie bis zur nächsten Worknote.
• Eine Worknote auf tieferer Ebene beendet die übergeordnete nicht, sondern überschreibt sie nur innerhalb ihres eigenen Bereichs.
• Worknotes müssen auf einer eigenen Zeile bzw. in einem eigenen Absatz stehen. Inline eingebettete Worknotes werden nicht ausgewertet.

6.2 Auswertungsregel

Enthält ein Dokument mehrere Worknotes, ist die Gesamtaussage die höchste vorkommende Role:-Stufe. Nur wenn genau eine Worknote existiert, ist sie unmittelbar die Dokumentaussage.

Begründung: Die erste Worknote ist in zusammengesetzten Dokumenten zufällig erste — sie als Gesamtaussage zu lesen wäre der gefährlichste Fehler. Die Maximum-Regel folgt dem Asymmetrie-Prinzip (5.1).

Daraus folgt:

• Wer bewusst eine Dokument-Worknote und Abschnitts-Worknotes führt, muss in der Dokument-Worknote mindestens die höchste vorkommende Stufe ausweisen.
• Human:, Status:, Labels:, AI checks: und AI history: zählen nur auf Dokumentebene. In Segment-Worknotes sind sie nicht ungültig, aber wirkungslos (5.2). Segment-Worknotes tragen wirksam nur Role: und optional Reviews:.
• Ohne eindeutige Dokument-Worknote hat ein Dokument keinen gültigen Status:. Es kann insbesondere nicht Approved sein und wird von nachgelagerten Prozessen als ungeprüft behandelt (Kapitel 7). Damit erzwingt die Konvention vor Freigabe und Veröffentlichung eine bewusste menschliche Konsolidierung.

6.3 Voll- und Kurzform

KI-Systeme geben standardmäßig die Vollform aus, weil sie für ihre eigene Ausgabe zutreffend ist. Für Agenten-Pipelines, deren Ausgabe bekanntermaßen immer Fragment ist, kann der Systemprompt auf die Kurzform gestellt werden (Abschnitt 9.2).

6.4 Konsolidierung

Konsolidieren heißt: eine Vollform an den Dokumentanfang setzen, verbleibende Segment-Worknotes auf Kurzform kürzen oder entfernen.

• Konsolidieren, wenn die Segmentierung nur die Entstehung abbildet und keine Aussage mehr trägt.
• Differenziert lassen, wenn die Granularität Information trägt — etwa ein KI-erstelltes Kapitel in einem sonst menschlich verfassten Bericht.
• Beim Konsolidieren gilt für die einzelnen Felder:
  • Role: = höchste vorkommende Stufe
  • Reviews: und AI checks: = nur übernehmen, was für das ganze Dokument gilt; sonst - bzw. weglassen
  • AI history: der Abschnitte wird weggelassen, nicht zusammenkopiert — das Zusammenführen mehrerer Ketten wird schnell unübersichtlich und trägt selten Information. Wer die Entstehung dokumentieren will, schreibt auf Dokumentebene eine neue, kurze AI history: mit höchstens einem Eintrag je wesentlicher Quelle
• Konsolidierung ist eine menschliche Entscheidung (5.3).

6.5 Bekannte Restrisiken

• Wird nur ein Textteil ohne die zugehörige Worknote kopiert, entsteht unmarkierter KI-Inhalt. Das ist technisch nicht verhinderbar und wird nur durch das Asymmetrie-Prinzip und Konsolidierungsdisziplin abgefedert.
• Die Worknote ist Freitext ohne Integritätsschutz. Sie kann irrtümlich oder absichtlich falsch gesetzt werden. Die Konvention beansprucht Transparenz, keine Fälschungssicherheit.

7. Konsumregeln

Die Worknote ist nicht nur zu schreiben, sondern auszuwerten. Für nachgelagerte Rollen und Prozesse gilt:

K1 — Redakteur. Vor der Veröffentlichung: Dokument-Worknote suchen, bei Mehrfachvorkommen die Auswertungsregel (6.2) anwenden, externes Label nach Kapitel 8 ableiten, Ergebnis in Labels: dokumentieren, Worknote aus der zu veröffentlichenden Fassung entfernen und den internen Stand sichern (5.8). Bei unklarer Lage gilt Fail-Closed: im Zweifel kennzeichnen.

K2 — Automatisierter Publikationsprozess. Fehlt eine Worknote, ist sie nicht parsbar oder enthält sie Labels: - bzw. Labels: pending, wird die Veröffentlichung entweder gestoppt oder mit Kennzeichnung durchgeführt. Ein Ausbleiben der Kennzeichnung darf nie die Folge einer fehlenden oder unlesbaren Angabe sein.

K3 — Aufbau von SOPs, Skills und Wissensartefakten. Aufgenommen werden nur Inhalte mit eindeutiger Dokument-Worknote, Status: Approved und mindestens einem abgeschlossenen Review. Inhalte mit Reviews: - werden nicht als Wissensbasis verwendet — ungeprüfter KI-Output darf nicht zur Grundlage neuer KI-Artefakte werden. Für das Ergebnis gilt die Vererbungsregel (5.7).

K4 — Injektion in Wissensdatenbanken (RAG). Die Worknote wird beim Ingest ausgewertet und als Metadatum an alle Chunks des Dokuments vererbt, nicht nur an den ersten. Fehlt sie, wird „keine Aussage” gesetzt, nicht None (5.4). Optional kann Status: als Filter für die Aufnahme in produktive Indizes dienen.

K5 — KI-Assistenten und Agenten. Reviews: -, Status: Draft und Role: AI-drafted sind Vertrauenssignale. Inhalte mit diesen Werten werden nicht ungeprüft in Kundenkommunikation, Entscheidungsvorlagen oder veröffentlichte Artefakte übernommen; stattdessen wird auf den ungeprüften Stand hingewiesen.

8. Ableitung externer Labels

Fachliche Orientierung, keine Rechtsberatung. Referenzregelwerk: EU AI Act Art. 50 (ab 02.08.2026) mit Code of Practice; andere Regelwerke (Plattformen, Kundenauflagen, weitere Jurisdiktionen) analog, jeweils mit eigener Angabe in Labels:.

Drei Punkte des Referenzregelwerks stützen den Aufbau dieser Konvention:

• Eine redaktionelle Prüfung mit Verantwortungsübernahme durch einen Menschen befreit veröffentlichte Texte von der Kennzeichnungspflicht — deshalb sind Reviews: und Status: Approved eigene Dimensionen.
• Eine Rechtschreibprüfung genügt dafür ausdrücklich nicht, und eine zweite KI ersetzt die menschliche Prüfung nicht — daher die Kennzeichnungsschwelle (3.1) und die strikte Trennung von AI checks: und Reviews: (4.1).
• Die maschinenlesbare Anbieter-Markierung (Art. 50 Abs. 2) greift für bereits im Markt befindliche Systeme erst ab 02.12.2026; bis dahin lässt sich für die Betreiberpflicht nicht auf Anbieter-Metadaten aufbauen.

8.1 Entscheidungslogik

1. Ist der Inhalt zur Veröffentlichung an Externe bestimmt? Wenn nein: keine externe Kennzeichnung, Labels: bleibt -.
2. Ist der Inhalt ganz oder wesentlich durch KI erzeugt oder verändert? Maßgeblich ist Role:.
3. Gab es eine qualifizierte menschliche Prüfung, und trägt eine Person oder Organisation die redaktionelle Verantwortung? Qualifiziert heißt: substanzielle inhaltliche Prüfung durch Personen mit einschlägigem Fachwissen und Urteilsvermögen — nicht bereits jede formale Durchsicht.

8.2 Mapping

Die Labeltexte in der Empfehlungsspalte entsprechen den Kennzeichnungen des EU Code of Practice („AI generated”, „AI modified” sowie das Kurzlabel „AI” mit erläuterndem Klartext).

Für das Mapping zählt nur Human: edited. Human: directed allein ersetzt weder eine Bearbeitung noch eine Prüfung und führt zu keiner anderen Einstufung.

8.3 Grenzen des Mappings

Die Worknote enthält nicht alle Informationen, die eine rechtssichere Entscheidung erfordert — insbesondere nicht den Umfang der menschlichen Bearbeitung (Human: edited sagt nur, dass bearbeitet wurde) und nicht die Qualifikation der prüfenden Personen. Wo die Angaben nicht ausreichen, ist beim Autor nachzufragen; bleibt die Lage unklar, wird gekennzeichnet (Fail-Closed).

9. Systemprompts

Zwei Fassungen, beide ohne Sonderzeichen im Prompttext (Gemini-kompatibel): die Kurzfassung (Abschnitt 3.6, ~850 Zeichen) für den Start, die Kompaktfassung unten (~2.150 Zeichen) mit Hilfe-Kommandos und Dokumentmodus — gedacht für Oberflächen mit Zeichenlimit (z. B. ChatGPT: 5.000 Zeichen gesamt). <System> beim Einfügen durch den Produktnamen ersetzen oder der KI überlassen.

Aufteilung nach Zweck: Was zum Schreiben der Zeile nötig ist, steht vollständig im Prompt und funktioniert ohne Netz. Was nur zum Erklären und Prüfen gebraucht wird, darf nachgeschlagen werden — der Abruf der Referenzseite ist dabei reine Wissensnutzung, kein Ausführen fremder Anweisungen. Gegen eine Abhängigkeit des Kernverhaltens sprechen zwei Gründe: In vielen Unternehmens-Setups ist Webzugriff deaktiviert, und die Antwort wird dann still erfunden; außerdem ist nicht reproduzierbar, was ein Modell aus einem langen Dokument extrahiert.

Dauerhaft oder punktuell: Für „Zeile bei jeder Ausgabe” ist der Systemprompt der einzige tragfähige Weg — je nach Produkt heißt das Feld „Anweisungen”, „Custom Instructions”, „Personal Context” oder „Preferences”. Punktuelle Werkzeuge — per @ gerufene Custom GPTs oder Copilot-Agenten, Gems, Skills — wirken nur für den jeweiligen Aufruf und eignen sich daher für Hilfe, Prüfung und Nachschlagen, nicht für das laufende Kennzeichnen. Wer die Spezifikation dort verfügbar machen will, hinterlegt sie als Wissensdatei, statt sie zur Laufzeit abzurufen.

9.1 Kompaktfassung (alles in einem)

=== AI-WORKNOTE ===
Kennzeichne jede von dir erzeugte oder materiell veränderte Textausgabe.

KOPFZEILE (erste Zeile bzw. direkt unter dem Titel):
ai-worknote.org/0.9: Role: <Wert> (<System>) / Human: - / Status: Draft / Reviews: -
<System> = dein Produktname (M365 Copilot, ChatGPT, Claude, Gemini ...).

ROLE - was DU getan hast:
- AI-drafted: Text von dir formuliert, auch Zusammenfassungen als eigener Text
- AI-revised: menschlichen Text umgearbeitet; Übersetzung: (<System>, translated)
- AI-assisted: nur Zuarbeit (Recherche, Ideen, Gliederung)
- None: kein KI-Beitrag
Reine Rechtschreib-, Grammatik- oder Formathilfe: keine Kopfzeile.

NUR DER MENSCH setzt Human, Status, Reviews und Labels. Gib immer die
Startwerte aus, übernimm vorhandene Angaben unverändert, erfinde nichts.
Zulässige Werte:
- Human: - | directed (Entstehung geführt) | edited (Text bearbeitet) | beides
- Status: Draft | In review | Approved (+ Veröffentlichungsstatus, siehe Spec)
- Reviews: - | <Art> <open|in progress|done> (<Person>, <Datum>); mehrere mit "; "

WEITERE REGELN:
- Ein KI-Entwurf bleibt AI-drafted, auch nach menschlicher Bearbeitung.
- Unklare Herkunft des Ausgangstexts: höhere Stufe (drafted > revised > assisted).
- Nie herabstufen. Fremde Worknotes nie entfernen oder verschmelzen.
- "ohne worknote": Kopfzeile weglassen, bis "mit worknote" folgt.

HILFE - bei Bedarf ai-worknote.org/0.9 nachschlagen, sonst dorthin verweisen:
- "worknote hilfe": Format und Werte kurz erklären.
- "worknote human?": DIESEN Verlauf beurteilen - beobachtbaren menschlichen
  Beitrag nennen, einen Human-Wert empfehlen, nicht setzen.
- "worknote prüfe: <Zeile>": gegen das Format prüfen, Korrektur vorschlagen.
- "worknote erkläre: <Zeile>": in 2-3 Sätzen erklären.

DOKUMENTE (Word/PDF/Präsentation/Tabelle):
- Genau eine Kopfzeile: Word/PDF als Absatz unter dem Titel; Präsentation im
  Untertitel der Titelfolie; Tabelle in Zelle A1 eines Blatts "Info".
- Echte Überschrift-Formatvorlagen, lückenlose Ebenen, automatische verknüpfte
  Kapitelnummerierung, ab 4 Überschriften Inhaltsverzeichnis als Feld.
  Keine Pseudo-Überschriften, keine getippten Nummern.

9.2 Zusatz für agentische Systeme

Du arbeitest agentisch an Inhalten, die Teil größerer Dokumente werden können.
- Gib deine Worknote in Kurzform aus: Kopfzeile wie oben, aber nur mit Role.
- Entferne und verschmelze keine vorhandenen Worknotes.
- Werte vorhandene Worknotes aus: Inhalte mit "Reviews: -" oder "Status: Draft"
  gelten als ungeprüft und werden nicht ungeprüft in Kundenkommunikation,
  Entscheidungsvorlagen oder Veröffentlichungen übernommen.
- Neues Artefakt aus mehreren Quellen: höchste vorkommende Role-Stufe,
  Status Draft, Reviews -. Optional Entstehungskette in "AI history:".

10. Referenz-URL, Versionierung, Lizenz

10.1 Referenz-URL

Die Worknote beginnt mit dem Anker ai-worknote.org/<Version>: — ohne Schema, ohne abschließenden Schrägstrich, kleingeschrieben. Der Anker ist zugleich Kennung, Versionsangabe und Nachschlage-Hinweis; Sonderzeichen wie eckige Klammern werden bewusst vermieden (Abschnitt 3.6). Beim Lesen werden Varianten toleriert (mit https://, mit www., mit Schrägstrich, abweichende Groß-/Kleinschreibung, ältere Klammerform).

Optionales Feld Ref:. In Dokumentwerkzeugen (Word, PDF, Präsentationen) werden schemalose Adressen nicht automatisch verlinkt. Wo ein klickbarer Verweis gewünscht ist — etwa bei Weitergabe an Externe — kann als letztes Feld Ref: https://ai-worknote.org/<Version> ergänzt werden. Im Alltag und in Segment-Worknotes entfällt es.

Identifier-first-Prinzip: Die URL ist in erster Linie eine Kennung und erst in zweiter Linie ein Verweis. Keine Auswertung darf davon abhängen, dass die Adresse erreichbar ist.

Die Seite wird ausschließlich über HTTPS ausgeliefert. In Kontexten, in denen eine vollständige Adresse zweckmäßiger ist (Terminal, Code-Kommentar), ist https://ai-worknote.org/<Version> als Variante zulässig.

10.2 Versionierung

Jede Version erhält einen eigenen Pfad und bleibt dauerhaft erreichbar. Versionen unter 1.0 kennzeichnen die Erprobungsphase: Änderungen sind ohne Rückwärtskompatibilitätszusage möglich. Ab 1.0 gilt: Ergänzungen erhöhen die Nebenversion, inkompatible Änderungen die Hauptversion.

10.3 Lizenz und Namensnutzung

• Spezifikationstext: CC BY-ND 4.0 — Weitergabe und Vervielfältigung frei, auch kommerziell, unter Namensnennung; Bearbeitungen und Übersetzungen bedürfen der Zustimmung, die auf Anfrage erteilt werden kann. Warum ND: Eine verbindliche Fassung je Version, keine kursierenden Varianten (Motiv wie bei W3C-Dokumentlizenzen). Übersetzungen und sektorale Profile: erwünscht, auf Anfrage; die Lizenz wird bei wachsender Beteiligung überprüft.
• Format und Anwendung: uneingeschränkt frei. Die Verwendung der Worknote in eigenen Dokumenten erfordert keine Erlaubnis, keine Registrierung und keine Nennung.
• Name: Der Name „AI-Worknote” soll nur für Nutzungen verwendet werden, die dieser Spezifikation entsprechen. Abgewandelte Fassungen sollen unter eigenem Namen geführt werden.

10.4 Herausgeber

10.5 Praxistipps

• Metadaten als Ergänzung: Die Worknote kann zusätzlich in Dokumenteigenschaften oder Systemmetadaten kopiert werden (z. B. Kommentarfeld der Dateieigenschaften, DMS-Spalte). Maßgeblich bleibt die Worknote im Text — Metadaten überleben Kopieren und Formatwechsel nicht.
• Unsichtbare Worknote — nur mit Bedacht: Um bei Veröffentlichungen keine separate Kopie führen zu müssen, kann die Worknote im Dokument verbleiben und lediglich unsichtbar formatiert werden (z. B. weiße Schrift, ausgeblendeter Text). Sie bleibt dann über die Suche auffindbar. Zu beachten: Der Inhalt ist damit nicht entfernt — jeder Empfänger kann ihn durch Markieren, Kopieren oder Suchen sichtbar machen. Diese Variante ist daher nur geeignet, wenn die Worknote keine Personenangaben (Stufe 3 oder 4 des Personenkatalogs, Abschnitt 3.3) und keine schutzbedürftigen internen Angaben enthält. Für alle anderen Fälle gilt Abschnitt 5.8: entfernen und intern archivieren.

Anhang A — Beispiele

Mehrzeilige Darstellung ist zulässig, wo eine lange Zeile unpraktisch ist. Der Block muss mit einer Leerzeile (bzw. einem leeren Absatz) abgeschlossen werden, damit sein Ende eindeutig erkennbar ist; jede Zeile beginnt mit einem Feldnamen:

ai-worknote.org/0.9:
Role: AI-drafted (M365 Copilot)
Human: edited
Status: Approved
Reviews: Editorial done (Jane Doe, 22.07.2026); Legal done (Legal, 23.07.2026)

Anhang B — Kanonische Syntax und Validierung

B.1 Grammatik (vereinfacht)

worknote   = domain "/" version ":" SP field *( " / " field )
field      = "Role: " rolevalue
           / "Human: " ( "-" / humanvalue *( ", " humanvalue ) )
           / "Status: " statusvalue
           / "Reviews: " ( "-" / reviewlist )
           / "AI checks: " ( "-" / reviewlist )
           / "Labels: " ( "-" / labellist )
           / "AI history: " historylist
           / "Ref: " url
rolevalue  = ( "AI-drafted" / "AI-revised" / "AI-assisted" / "None" ) [ SP "(" params ")" ]
reviewlist = review *( "; " review )
review     = kind SP ( "open" / "in progress" / "done" ) [ SP "(" params ")" ]
labellist  = label *( "; " label )
label      = ( DQUOTE text DQUOTE / "none" / "pending" ) [ SP "(" params ")" ]
humanvalue = "directed" / "edited"
params     = text *( ", " text )

Reihenfolge der Felder in der kanonischen Form: Role, Human, Status, Reviews, AI checks, Labels, AI history, Ref.

B.2 Erkennungs-Regex (tolerant)

(?:https?:\/\/)?(?:www\.)?ai-worknote\.org\/(\d+\.\d+)\/?\s*:\s*(.*)

B.3 Prüfung der Pflichtfelder (kanonisch)

^ai-worknote\.org\/\d+\.\d+:\s+Role:\s*(AI-drafted|AI-revised|AI-assisted|None)(\s*\([^)]*\))?(\s*\/\s*Human:\s*[^\/]+)?(\s*\/\s*Status:\s*[^\/]+)?(\s*\/\s*Reviews:\s*[^\/]+)?.*$

B.4 Prüfschritte eines Validators

1. Präfix und Version erkennen; unbekannte Version → Hinweis, nicht Fehler.
2. Role: vorhanden und zulässiger Wert.
3. Auf Dokumentebene: Human:, Status: und Reviews: vorhanden.
4. Mehrfachvorkommen im Dokument → Hinweis „nicht konsolidiert”, kein Fehler.
5. Bei vorhandener Dokument-Worknote und Abschnitts-Worknotes: Dokumentwert ≥ höchste Abschnittsstufe (Aggregationsregel).
6. Abweichungen von der kanonischen Form → Normalisierungsvorschlag, kein Fehler.

Anhang C — Änderungen gegenüber früheren Entwürfen

Bezugspunkt ist der interne Entwurf vom 23.07.2026, der nicht ausgerollt wurde. Die Nummer 0.9 kennzeichnet die Feldtest-Phase; 1.0 wird die erste Freigabeversion nach dem Pilot.

Anhang D — Offene Punkte für Version 1.0

Diese Liste ist Teil der Feldtest-Fassung und wird bis zur Freigabe von 1.0 abgearbeitet. Sie macht transparent, was bewusst noch offen ist.

Struktur und Redaktion - Kapitelstruktur konsolidieren: Teil A und Teil B als getrennte Dokumente prüfen; Nummerierung danach einmalig bereinigen (u. a. Abschnitt 5.4a) - Cheat-Sheet als eigenes Einseiten-Artefakt aus Teil A ableiten - Englische Fassung; kanonische Maschinenfassung (spec.md)

Inhaltlich zu erproben - Ist das Feld Human: im Alltag verständlich, oder wird es systematisch vergessen? - Wird Human: directed inflationär verwendet? Trägt die Schwelle „mehrere Runden mit substanziellen Entscheidungen”? - Ist die Zwei-Bedingungen-Regel zum Weglassen (1.5) intuitiv anwendbar? - Tragen die Konsumregeln (Kapitel 7) in echten RAG-/SOP-Prozessen? - Bewähren sich die Abschnittsregeln (Kapitel 6) bei zusammengesetzten Dokumenten? - Wird die Invalidierungsregel (3.3) in der Praxis befolgt?

Umsetzung und Werkzeuge - Validator, Explainer und Prompt-Generator als browserbasierte Werkzeuge - Vorlagen und Schnellbausteine für Textverarbeitung; Prüfung eines Add-ins - Referenzimplementierung eines Parsers

Governance und Recht - Rechtliche Durchsicht von Kapitel 8 vor dem Einsatz bei Kunden - Markenrecherche zum Namen; Entscheidung über Markenanmeldung - Lizenzmodell nach dem Feldtest überprüfen (CC BY-ND vs. offenere Modelle) - Rückmeldekanal und Kriterien für die Freigabe von 1.0 festlegen