Abgelehnte Vorschläge

Diese Seite listet Anker-Vorschläge auf, die bewertet wurden, aber die Qualitätskriterien für semantische Anker nicht erfüllen. Jeder Eintrag erklärt, warum der Vorschlag abgelehnt wurde.

Das Verständnis der Ablehnungsgründe hilft Mitwirkenden, bessere Vorschläge einzureichen und vermeidet die erneute Einreichung bereits bewerteter Begriffe.

Ablehnungskategorien

Strukturell ungeeignet

Der Begriff ist zu vage, hat keine definierte Methodik oder ist eine reine Anweisung statt eines Konzepts. Erfüllt das Precise- und/oder Rich-Kriterium nicht.

Unzureichende Trainingsdaten-Dichte

Ein legitimes Konzept oder Framework, das zwar wiedererkannt wird (Modelle können darüber reden), aber in der Ausgabe nicht zuverlässig aktiviert: Den Begriff zu nennen verändert das Ergebnis gegenüber einem allgemeinen Prompt strukturell nicht, oder er löst auf schwächeren Modellen stille Ersetzung oder Konfabulation aus. Erfüllt das Consistent-Kriterium nicht. Begriffe hier können mit wachsenden Trainingsdaten noch zu tragfähigen Ankern werden — bis dahin ist ein Semantic Contract (der seine Bedeutung selbst mitbringt) der richtige Ort. (Früher „Nicht in Trainingsdaten".)

Zu spezialisiert

Eine echte Methodik, aber zu spezialisiert für zuverlässige Aktivierung über verschiedene LLMs und Kontexte hinweg. Erfüllt das Consistent- und/oder Rich-Kriterium nicht.

Abgelehnte Vorschläge

Vorschlag Kategorie Begründung

TLDR

Strukturell ungeeignet

Unterspezifizierte Anweisung ohne definierte Struktur. Bedeutet nur "fasse dich kurz" ohne ein Framework dafür. Keine Methodik.
Jetzt verfügbar als Semantic Contract: "Concise Response" — kombiniert BLUF + Strunk & White.

ELI5 (Explain Like I’m 5)

Strukturell ungeeignet

Vages Zielniveau ohne pädagogisches Framework. Keine konsistente Interpretation dessen, was "Niveau eines 5-Jährigen" technisch bedeutet.
Jetzt verfügbar als Semantic Contract: "Simple Explanation" — nutzt die Feynman-Technik.

Spec-Driven Development (#356)

Strukturell ungeeignet

Relevantes Konzept, aber keine einheitliche Definition — verschiedene Interpretationen (API-first, formale Specs, unser Workflow). Nicht einem konkreten Urheber zuordenbar.
Jetzt verfügbar als Semantic Contracts: "Specification" + "Requirements Discovery" — kombiniert Gherkin, BDD, Sokratische Methode, MECE, PRD.

Explicit Contract Surface (#357)

Strukturell ungeeignet

Gut beschriebene Design-Praxis, aber kein etablierter Begriff in der Literatur. Kombiniert bestehende Anker (Clean Architecture, Hexagonal, DDD, SOLID DIP/ISP) ohne neue Aktivierung.
Jetzt verfügbar als Semantic Contract: "Layer Boundaries".

MIRRR UX Framework (#150)

Unzureichende Trainingsdaten-Dichte

Ein echtes UX-Framework mit definierter Methodik, aber nicht weit genug dokumentiert, damit LLMs es zuverlässig erkennen und die richtigen Konzepte aktivieren.

YOLO (#443)

Strukturell ungeeignet

Mehrdeutig und keine Methodik: entweder „You Only Look Once" (ein Computer-Vision-Modell, zu eng) oder das Motto „You Only Live Once" (reines Sentiment, wie TLDR). Keine konsistente Aktivierung, keine umsetzbare Struktur.
Die im Thread genannte Idee „rapid exploration / permission to bypass" lässt sich besser durch Komposition bestehender Anker ausdrücken (Spike Solution, Walking Skeleton, MVP) innerhalb der Complex-/Chaotic-Domänen des Cynefin-Frameworks.

Kanban (TPS) (#769)

Unzureichende Trainingsdaten-Dichte

Vorgeschlagen als die Toyota-Signalkarte, das physische Kanban, das eine Nachlieferung auslöst. Der Prior ist nicht dünn — er hängt am gleichnamigen anderen Begriff, und er ersetzt still. Auf den nackten Namen liefern beide Stufen die Software-Methode Kanban (David J. Anderson): Die starke Stufe beginnt „Kanban is a pull-based method for managing work, originating in Toyota’s manufacturing system and later adapted for software and knowledge work (largely via David Anderson’s formulation)" — Toyota steht nur als Etymologie da, dann geht die Antwort zu Boards und WIP-Limits.
Ein Steuerungstest auf einem neutralen Szenario entscheidet: Die Ausgabe trägt acht Marker der Software-Methode (WIP-Limits, Commitment Point, Classes of Service, Replenishment, STATIK, Cumulative Flow Diagram) und null Marker der Fertigungspraxis — keine Signalkarte, kein Supermarkt, kein Zwei-Behälter-System, kein Materialfluss. Die Antwort unterscheidet die Lesarten nie; sie setzt die Software-Lesart voraus. Ein Qualifier repariert das nicht, er würde gegen den Prior arbeiten statt ihn zu fokussieren.
Die Software-Lesart bleibt als eigener Vorschlag offen — unter dem Namen, der sie tatsächlich aktiviert: „Kanban Method (Anderson)". Dieser Kandidat wurde nicht geprüft. Vollständige Messung im Prior-Test-Register, Lauf vom 30.09.2026. Die übrigen 15 Begriffe desselben Clusters (#753) wurden aufgenommen.

Begriffe, die nicht als Semantic Anchors qualifizieren, können trotzdem als Semantic Contracts nützlich sein. Ein Contract definiert, was ein Begriff in deinem Projekt bedeutet — entweder durch Komposition etablierter Anker oder durch eigene Definitionen, die nur in deinem Team existieren.

Wie wir bewerten

Jeder Vorschlag wird gegen unsere vier Qualitätskriterien getestet:

  1. Precise — Referenziert er ein spezifisches, etabliertes Wissensgebiet?

  2. Rich — Aktiviert er mehrere zusammenhängende Konzepte?

  3. Consistent — Verstehen verschiedene LLMs ihn zuverlässig gleich?

  4. Attributable — Lässt er sich auf Schlüsselvertreter oder Publikationen zurückführen?

Wir testen, indem wir ein LLM fragen:

Welche Konzepte verbindest du mit '<vorgeschlagener Begriff>'?

Wenn die Antwort vage ist, über Modelle hinweg inkonsistent, oder kein kohärentes Wissensgebiet aktiviert, qualifiziert sich der Vorschlag nicht.

Siehe Über für die vollständigen Qualitätskriterien und Beispiele.