# 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

| Sie …                                  | Ausreichend sind                             |
| -------------------------------------- | -------------------------------------------- |
| schreiben Texte mit KI-Unterstützung   | Kapitel 2 und 3                              |
| prüfen oder geben Dokumente frei       | zusätzlich Abschnitte 3.3, 3.4 und Kapitel 5 |
| veröffentlichen Inhalte nach außen     | zusätzlich Abschnitt 4.2 und Kapitel 8       |
| bauen Werkzeuge, Prozesse oder Agenten | zusätzlich Kapitel 6, 7, 9 und Anhang B      |

**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:

| | **Intern** | **Extern** |
|---|---|---|
| Artefakt | AI-Worknote | Endnutzer-Label (z. B. „AI generated" gemäß EU Code of Practice) |
| Zielgruppe | Autoren, Mitwirkende, Konsumenten, Redakteure, nachgelagerte Prozesse | Externe Empfänger, Kunden, Öffentlichkeit |
| Geltung | gesamter Lebenszyklus | veröffentlichte Fassung |
| Rolle | Quellinformation und Nachweis | Ergebnis der Kennzeichnungsentscheidung |

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:

| Angabe | Wer sie setzt | Charakter |
|---|---|---|
| `Role:` | KI-System oder Autor | Selbstauskunft über den Beitrag |
| `Reviews:`-Eintrag | die prüfende Person selbst | persönliche Bestätigung der Prüfung |
| `Status: Approved` | eine dazu befugte Person | organisatorische Feststellung |
| `Labels:` | Mensch oder autorisierter Publikationsworkflow | Kennzeichnungsentscheidung |

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

| Feld | Pflicht | Zulässige Werte |
|---|---|---|
| `Role:` | ja | `AI-drafted` (Stufe 3) · `AI-revised` (Stufe 2) · `AI-assisted` (Stufe 1) · `None` (Stufe 0), mit `(<System>)`, optional `(<System>, translated)` |
| `Human:` | ja (Dokumentebene) | `-` (kein Beitrag) · `directed` (Entstehung geführt) · `edited` (Text bearbeitet); kombinierbar |
| `Status:` | ja (Dokumentebene) | `Draft` · `In review` · `Approved`; optional `For publication` · `Scheduled` · `Published` · `Archived` · `Withdrawn` · `Rejected` |
| `Reviews:` | ja (Dokumentebene) | `-` oder `<Art> <open\|in progress\|done> [(<Person>[, <Datum>])]` |
| `AI checks:` | nein (Dokumentebene) | wie `Reviews:`, jedoch KI-gestützte Prüfungen |
| `Labels:` | nein (Dokumentebene) | `-` · `pending (<Regelwerk>)` · `none (<Regelwerk>, <Begründung>)` · `"<Labeltext>" (<Regelwerk>)` |
| `AI history:` | nein (Dokumentebene) | chronologische Einträge `<Datum> <Role-Wert> (<System>)`, getrennt durch `; ` |

---

## 3. Die Pflichtfelder

### 3.1 Role — materieller KI-Anteil

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

| Stufe | Wert | Bedeutung |
|:-:|---|---|
| 0 | `None` | Kein KI-Einsatz an diesem Inhalt. |
| 1 | `AI-assisted` | KI hat inhaltlich unterstützt, ohne den Text zu schreiben oder zu überarbeiten (Recherche, Ideenfindung, Gliederungsvorschläge, Zusammenfassen von Quellen als Vorarbeit). |
| 2 | `AI-revised` | KI hat einen **menschlich verfassten** Text materiell überarbeitet (umformuliert, gekürzt, umstrukturiert, erweitert). |
| 3 | `AI-drafted` | Ein **KI-Entwurf** prägt die vorliegende Fassung. |

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?

| Wert | Bedeutung |
|---|---|
| `-` | Kein wesentlicher menschlicher Beitrag (Default bei KI-Ausgaben). |
| `directed` | Ein Mensch hat die Entstehung **inhaltlich geführt**: Ziele gesetzt, eigene Inhalte beigesteuert, Vorschläge verworfen, Entscheidungen getroffen — ohne den Text selbst zu schreiben. |
| `edited` | Ein Mensch hat den **Text selbst** wesentlich bearbeitet — umgeschrieben, ergänzt, gekürzt, fachlich angepasst. |

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.

| Wert | Bedeutung |
|---|---|
| `Draft` | In Bearbeitung, nicht zur Nutzung freigegeben. |
| `In review` | In Prüfung. |
| `Approved` | Freigegeben. |

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:

| Stufe | Form | Empfohlen für |
|---|---|---|
| 1 | Funktion/Rolle `(Legal)` | **Default** — datensparsam, auch bei Weitergabe unkritisch |
| 2 | Kürzel `(JD)` | interne Nutzung, wenn Personenbezug gewünscht, aber diskret |
| 3 | Klarname `(Jane Doe)` | bewusste Wahl für interne Nachvollziehbarkeit; nicht für Inhalte, die die Organisation verlassen können |
| 4 | keine Angabe | wo Personenbezug entbehrlich ist |
| 5 | Verweis `(s. Freigabeprotokoll)` | wo ein separater Nachweis geführt wird |

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.

| Ich habe … | Ich ändere in der Worknote |
|---|---|
| einen KI-Entwurf inhaltlich überarbeitet | `Human: -` → `Human: edited` |
| die Entstehung über mehrere Runden geführt (Ziele, Entscheidungen, eigene Inhalte) | `Human: -` → `Human: directed` |
| den Text fachlich/redaktionell geprüft | `Reviews: -` → `Reviews: Editorial done (Kürzel, Datum)`; `Status:` → `In review` |
| eine Prüfung begonnen, aber nicht beendet | `Reviews: Editorial in progress (Kürzel)`; `Status:` → `In review` |
| das Dokument freigegeben (und darf das) | `Status:` → `Approved` |
| nach der Freigabe inhaltlich geändert | `Status:` → `Draft`; betroffene Reviews → `open` |
| KI-Text in mein Dokument eingefügt | Dokument-Worknote prüfen: `Role:` ggf. hochstufen, nie herabstufen |
| den Text unverändert weitergegeben | nichts |
| nur Tippfehler oder Formatierung korrigiert | nichts |
| eine kurze, geprüfte Mail verschickt | Worknote ganz entfernen (1.5) |
| etwas veröffentlicht | Kennzeichnung prüfen (Kapitel 8), Worknote aus der veröffentlichten Fassung entfernen (5.8) |

**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.

| Wert | Bedeutung |
|---|---|
| `Labels: -` | Keine Prüfung erfolgt oder nicht einschlägig (Default). |
| `Labels: pending (EU CoP)` | Prüfung läuft. |
| `Labels: none (EU CoP, human review documented)` | Geprüft, kein Label erforderlich. |
| `Labels: "AI generated" (EU CoP)` | Label erforderlich bzw. angebracht. |
| `Labels: "AI modified" (EU CoP, documented); "With AI" (LinkedIn)` | Mehrere Regelwerke parallel. |

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

| Form | Verwendung |
|---|---|
| **Vollform** `ai-worknote.org/0.9: Role: … / Human: … / Status: … / Reviews: …` | Dokumentebene; Standardausgabe von KI-Systemen |
| **Kurzform** `ai-worknote.org/0.9: Role: AI-drafted (M365 Copilot)` | Abschnitts- und Segment-Worknotes, die bewusst erhalten bleiben |

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).

| `Role:` | Menschliche Bearbeitung und Prüfung | Empfehlung |
|---|---|---|
| `None` | — | keine Kennzeichnung |
| `AI-assisted` | — | in der Regel keine Kennzeichnung; bei Zweifeln wie `AI-revised` behandeln |
| `AI-revised` | ohne qualifizierte Prüfung | `"AI modified"` |
| `AI-revised` | mit qualifizierter Prüfung und redaktioneller Verantwortung | `none (…, human review documented)` |
| `AI-drafted` | ohne wesentliche menschliche Bearbeitung | `"AI generated"` |
| `AI-drafted` + `Human: edited` | ohne qualifizierte Prüfung | `"AI"` mit Klartexthinweis zur Art des KI-Einsatzes, alternativ `"AI modified"` |
| `AI-drafted` + `Human: edited` | mit qualifizierter Prüfung und redaktioneller Verantwortung | `none (…, human review documented)` |

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

| | |
|---|---|
| **Herausgeber** | Carsten Blau, AUFWERT GmbH |
| **Kontakt** | LinkedIn: linkedin.com/in/carstenblau · E-Mail: siehe ai-worknote.org |
| **Entstehung** | Konzipiert und verantwortet vom Herausgeber; ausgearbeitet mit Unterstützung mehrerer KI-Systeme. Der KI-Anteil dieses Dokuments ist in seiner eigenen Worknote am Dokumentanfang ausgewiesen. |

### 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

| Situation | Worknote |
|---|---|
| Chatbot-Antwort, unverändert | `ai-worknote.org/0.9: Role: AI-drafted (M365 Copilot) / Human: - / Status: Draft / Reviews: -` |
| KI-Entwurf, über viele Runden vom Menschen geführt | `ai-worknote.org/0.9: Role: AI-drafted (M365 Copilot) / Human: directed / Status: Draft / Reviews: -` |
| KI-Entwurf, vom Autor überarbeitet | `ai-worknote.org/0.9: Role: AI-drafted (ChatGPT Enterprise) / Human: edited / Status: Draft / Reviews: -` |
| Menschlicher Text, von KI sprachlich überarbeitet | `ai-worknote.org/0.9: Role: AI-revised (Claude) / Human: - / Status: In review / Reviews: Editorial in progress (JD)` |
| Menschlicher Text, von KI übersetzt | `ai-worknote.org/0.9: Role: AI-revised (ChatGPT Enterprise, translated) / Human: - / Status: Draft / Reviews: -` |
| KI nur zur Recherche genutzt | `ai-worknote.org/0.9: Role: AI-assisted (Perplexity) / Human: - / Status: Draft / Reviews: -` |
| Rein menschlicher Text (`Human:` entfällt) | `ai-worknote.org/0.9: Role: None / Status: Approved / Reviews: Editorial done (Legal, 20.07.2026)` |
| Freigegebenes Dokument mit zwei Prüfungen | `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)` |
| Mit KI-Prüfung ergänzt | `ai-worknote.org/0.9: Role: AI-drafted (Claude) / Human: - / Status: In review / Reviews: Editorial open / AI checks: Factuality done (Claude)` |
| Vor Veröffentlichung, Kennzeichnung entschieden | `ai-worknote.org/0.9: Role: AI-drafted (Claude) / Human: - / Status: For publication / Reviews: Editorial done (JD) / Labels: "AI generated" (EU CoP)` |
| Geprüft, keine Kennzeichnung nötig | `ai-worknote.org/0.9: Role: AI-revised (Gemini) / Human: edited / Status: Published / Reviews: Editorial done (Jane Doe, 24.07.2026) / Labels: none (EU CoP, human review documented)` |
| Abschnitts-Worknote (Kurzform) | `ai-worknote.org/0.9: Role: AI-drafted (M365 Copilot)` |
| Agenten-Pipeline mit Historie | `ai-worknote.org/0.9: Role: AI-drafted (Claude Cowork) / Human: - / Status: Draft / Reviews: - / AI history: 2026-07-20 AI-drafted (M365 Copilot); 2026-07-22 AI-revised (Claude Cowork)` |

**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)

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

### B.3 Prüfung der Pflichtfelder (kanonisch)

```regex
^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.

| # | Änderung | Grund |
|---|---|---|
| 1 | Standardname und Referenz-URL eingeführt: Präfix `ai-worknote.org/0.9:` statt `[AI]` | Selbstreferenzierend; externe Beteiligte können nachschlagen; Versionierung eingebaut |
| 2 | Role-Werte umbenannt: `AI-drafted`, `AI-revised`, `AI-assisted` | Auflösung der Kollision zwischen `Drafted` und `Status: Draft`; Richtung von `revised` wird explizit |
| 3 | Merksatz „Role beschreibt, was die KI getan hat" ergänzt | Häufigster vorhersehbarer Anwendungsfehler |
| 4 | Eigenes Feld `Human:` für die menschliche Bearbeitung (statt Zusatz in `Role:`) | Schließt die Informationslücke bei der Ableitung externer Labels; hält das Prinzip „ein Feld = ein Akteur" durch |
| 5 | Review-Fortschritt von Prozentangaben auf `open`/`in progress`/`done` umgestellt | Vermeidet Scheinpräzision und die Fehldeutung „100 % = fehlerfrei"; entspricht dem klassischen Prüfvermerk |
| 6 | Stufenkatalog für Personenangaben | Datenschutz, externe Weitergabe |
| 7 | `EU Art. 50:`-Block durch generisches Feld `Labels:` ersetzt | Kürzer; deckt beliebige Kennzeichnungsregime ab; dokumentiert das Ergebnis statt einer Bewertungsformel |
| 8 | Asymmetrie-Prinzip explizit gemacht | Erklärt den Fail-Safe-Charakter und den Pflegeanreiz |
| 9 | Prinzip „streng schreiben, tolerant lesen" | Macht Formatvarianz und Tippfehler handhabbar |
| 10 | Regel „fehlende Worknote bedeutet keine Aussage" | Voraussetzung für schrittweise Einführung und Bestandsinhalte |
| 11 | Regeln für Einfügen, Zusammenführen, Vererbung und Pflegeverantwortung | Bisher ungeregelte Alltagsfälle |
| 12 | Regeln für die Veröffentlichung: entfernen und archivieren | Schließt Datenschutz- und Nachweislücke |
| 13 | Kapitel 6 neu: Geltungsregel, Auswertungsregel, Voll-/Kurzform, Konsolidierung | Zusammengesetzte Dokumente sind Normalfall, bisher ungeregelt |
| 14 | Kapitel 7 neu: Konsumregeln | Der Standard regelte bisher nur das Schreiben, nicht das Auswerten |
| 15 | Systemprompt-Variante für generierte Dokumente mit Strukturvorgaben | Vermeidet manuelle Nacharbeit an Überschriften und Nummerierung |
| 15a | Kurzfassung des Systemprompts um Beispiele je Role-Wert ergänzt | Ohne Beispiele wird die Zuordnung von `AI-revised` und `AI-assisted` unzuverlässig |
| 15b | Optionaler Hilfe-Abschnitt für Systemprompts (Abschnitt 9.5) | Kurze Rückfragen im Chat ohne Öffnen der Spezifikation |
| 19 | Kennzeichnungsschwelle eingeführt: rein mechanische/algorithmische Hilfe (Grammatik, Rechtschreibung, Autovervollständigung) gilt als `None` | Vermeidet „klein-klein"-Kennzeichnung und die unklare Abgrenzung KI vs. Algorithmus; entspricht dem Konsens im wissenschaftlichen Publizieren |
| 20 | Abschnitt 1.5 „Wann eine Worknote sinnvoll ist" plus Weglass-Regel (5.4a) | Risiko-/relevanzbasierter Einsatz statt flächendeckender Kennzeichnung; flüchtige, geprüfte, nicht aufbewahrte Inhalte brauchen keine Worknote |
| 21 | Stummschaltung in den Systemprompts („ohne worknote" / „mit worknote") | Erlaubt bewusstes Aussetzen ohne nachträgliches Löschen |
| 22 | Invalidierungsregel: materielle Änderung setzt `Approved`/abgeschlossene Reviews zurück | Schließt das gefährlichste Fehlerbild (veraltete Freigabe an geänderter Fassung); Kernkritik der externen Reviews |
| 23 | Abschnitt 1.6 „Was die AI-Worknote nicht ist" + Autoritätsmodell (wer darf was setzen) | Ehrliche Abgrenzung zu Provenienz-Standards, Compliance und DMS; unterscheidet Selbstauskunft, Prüfbestätigung und Freigabe |
| 24 | Umbenennung „Standard" → „offene Konvention (Feldtest)"; Kernprofil von experimentellen Erweiterungen getrennt | Reifegrad ehrlich darstellen; Feldtest-Fokus auf Role/Status/Reviews |
| 25 | Datenschutz-Default gedreht: Funktion/Rolle statt Klarname als Standard-Personenangabe | Datensparsamkeit; Klarnamen nur als bewusste interne Wahl |
| 26 | Abgrenzungshilfe Role-Stufen per Ursprungstest; bewusster Verzicht auf Prozent-Schwellen | Prozentanteile sind nicht messbar und nicht Best Practice; etablierte Regelwerke unterscheiden nach Mechanismus bzw. kreativer Kontrolle |
| 27 | Lizenzbegründung (warum ND) und Öffnungsklausel für Übersetzungen/Profile | Vermeidet Eindruck „offener Standard mit versteckter Kontrolle" |
| 28 | Sonderfall Übersetzung geregelt: `AI-revised` mit optionalem Zusatz `translated`, kein eigener Role-Wert | Chatbots wiesen Übersetzungen fälschlich als `AI-drafted` aus; Skala bleibt vierstufig und anschlussfähig |
| 29 | Dokument in Teil A (Essentials, cheat-sheet-fähig) und Teil B (Vertiefung) gegliedert; Schnellstart-Prompt als Abschnitt 3.4 | Neue Anwender werden nicht vom optionalen Teil abgeschreckt |
| 30 | Kurzfassungs-Prompt überarbeitet: verbale Klammerbeschreibung (Gemini-kompatibel), Fallliste inkl. Übersetzung/Zusammenfassung, Stummschaltung integriert | Ein Prompt für alle Chat-Oberflächen; Fehleinordnungen im Test behoben |
| 31 | Abschnitt 5.9: zehn typische Workflow-Übergänge (T1–T10) ausformuliert | Menschen und KI-Systeme können Zustandswechsel direkt nachvollziehen und anwenden |
| 32 | Systemprompts konsolidiert: Kompaktfassung 9.1 (~2.100 Z., inkl. Hilfe-Kommandos und Dokumentmodus) und Kurzfassung 3.4 (~900 Z.), beide ohne `[` im Prompttext | Zeichenlimits der Oberflächen (z. B. ChatGPT 5.000 Z.); Redundanz der Abschnitte 9.3/9.5 beseitigt; Gemini-Kompatibilität durchgängig |
| 33 | Kürzungspass: erläuternde Passagen kompakter formuliert | Lesbarkeit; normativer Gehalt unverändert |
| 34 | Abschnitt 1.1: „Warum das vorher nicht nötig war" (Autor als Provenienz, Kopplung durch KI zerschnitten) | Häufigster Einwand in der Fachdiskussion |
| 35 | Abschnitt 1.5: „Detailtiefe nach Bedarf" | Klärt, dass Kernprofil genügt und optionale Felder nur bei Nachweisbedarf nötig sind |
| 36 | Abschnitt 1.6: Abgrenzung zu technischen Ansätzen an der Quelle (Gateway, Ingestion-Guard, DLP) | Standardeinwand aus der IT; positioniert die Konvention als organisatorische Antwort ohne Infrastrukturvoraussetzung |
| 37 | Kapitel 8: drei rechtliche Anker ergänzt (redaktionelle Prüfung befreit; Rechtschreibprüfung und Zweit-KI genügen nicht; Anbieter-Markierung erst ab 02.12.2026) | Stützt Reviews/Status, Kennzeichnungsschwelle und die Trennung `AI checks:`/`Reviews:` |
| 38 | Kanonisches Format ohne eckige Klammern: Anker `ai-worknote.org/0.9:` statt `[ai-worknote.org/0.9]` | Klammern lösen bei manchen Chat-Oberflächen Injection-Filter aus; Anker ist kürzer, selbsterklärend und wird in vielen Werkzeugen automatisch verlinkt. Alte Form bleibt tolerierte Lesevariante |
| 39 | Optionales Feld `Ref:` für klickbare Verweise in Dokumentwerkzeugen | Schemalose Adressen werden in Word/PDF nicht automatisch verlinkt |
| 40 | Abschnitt 3.1: keine Modell-/Versionsangabe im Systemnamen; Zeitpunkt gehört in `AI history:` | Modelle kennen ihre Version nicht zuverlässig; Produktversionen sind tenant-abhängig |
| 41 | Abschnitt 4.3: `AI history:` wird von Menschen oder Agenten gesetzt, nicht von Chatbots | Vermeidet unzuverlässige Datumsangaben und hält die Standardprompts kurz |
| 42 | Neuer Abschnitt 3.5 „Was ändere ich wann?" mit Situations-Tabelle | Anwender wussten aus dem Stand nicht, welcher Handgriff wann nötig ist |
| 43 | `Human: -` ist Teil der Standardausgabe von KI-Systemen | Feld ist vorbelegt; Pflege bleibt ein Wortwechsel statt einer Ergänzung |
| 44 | Anhang D „Offene Punkte für Version 1.0" ergänzt; veraltete Verweise korrigiert; Stub-Abschnitt 9.2 entfernt | Transparenz über den Feldtest-Charakter; Lesefluss ohne Rücksprünge |
| 45 | Feld `Human:` um den Wert `directed` erweitert (Entstehung geführt, ohne den Text zu schreiben); Werte kombinierbar | Der häufigste Mitwirkungsmodus — iteratives Führen über viele Runden — war bisher unsichtbar; ein gesteuertes Dokument trug dieselbe Worknote wie eine ungelesene Ein-Prompt-Ausgabe |
| 46 | Hilfe-Kommando „worknote human?" ergänzt: KI schildert Beobachtungen und empfiehlt, setzt den Wert aber nicht | Nutzt den Kontextvorteil der KI, ohne das Prinzip „Mensch setzt menschliche Angaben" zu brechen |
| 47 | Zulässige `Human:`-Werte in beiden Systemprompts ausdrücklich aufgelistet; Kommando „worknote human?" auf die Beurteilung des konkreten Verlaufs geschärft | Im Test erfand ein Chatbot eigene Werte (`Reviewed (Name)`, `Approved`) und erklärte das Feld allgemein, statt den Verlauf zu bewerten |
| 48 | Zulässige `Status:`- und `Reviews:`-Werte ebenfalls in beide Prompts aufgenommen; Hinweis ergänzt, warum die Prompts selbsttragend sind | Gleiche Erfindungsgefahr wie bei `Human:`; Nachladen über die URL ist wegen fehlendem Webzugriff und Injection-Abwehr kein verlässlicher Ersatz |
| 49 | Lizenzangabe an den Dokumentanfang gezogen (Kurzform plus ausgeschriebene deutsche Fassung), Einzelheiten bleiben in 10.3 | Klarheit über die Nutzungsrechte vor dem Lesen, nicht danach |
| 50 | Beide Systemprompts gestrafft: kurze Sätze, Werte gebündelt; Kurzfassung von ~1.485 auf ~850 Zeichen | Weniger Token, geringere Variabilität |
| 51 | Aufteilung „selbsttragend fürs Schreiben, Nachschlagen für Hilfe und Prüfung"; Unterscheidung dauerhafter Systemprompt vs. punktuelle Werkzeuge | Korrigiert eine zu weite Auslegung der Injection-Abwehr: Nachschlagen ist Wissensnutzung; tragend sind fehlender Webzugriff und Reproduzierbarkeit |
| 16 | Quellcode-Anwendung auf Fälle ohne Versionskontrolle eingegrenzt | Commit-Trailer und Pull-Request-Freigaben bilden dasselbe genauer ab |
| 17 | Anhang B: kanonische Syntax, Regex, Validator-Prüfschritte | Ermöglicht maschinelle Auswertung |
| 18 | Lizenz- und Namensnutzungsregelung | Breite Verbreitung ohne Fremdadaptionen |

---

## 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