docs: add viability test to contribution guidelines

.github/ISSUE_TEMPLATE/propose-anchor.yml

@@ -71,6 +71,23 @@ body:
     validations:
       required: true
 
+  - type: textarea
+    id: viability-test
+    attributes:
+      label: Viability Test (Optional but encouraged)
+      description: |
+        Does naming this anchor actually change the LLM's output structure?
+        Give a model a task WITHOUT the anchor term, then the SAME task WITH the anchor.
+        See the training-data-vs-practice article for the full methodology.
+      placeholder: |
+        Task: "Specify what an online shop must do when a customer places an order."
+        Without anchor: [describe output structure]
+        With anchor: [describe output structure]
+        Structural difference: [what changed]
+        Weak model tested: [model name, result]
+    validations:
+      required: false
+
   - type: checkboxes
     id: checklist
     attributes:

CONTRIBUTING.adoc

@@ -65,6 +65,58 @@ Evaluate the response:
 * *Depth:* Does it cover multiple related concepts?
 * *Specificity:* Is the scope well-defined?
 
+== Viability Test — Does the Anchor Deliver?
+
+Recognition alone does not make a viable anchor. The link:docs/training-data-vs-practice.adoc[training-data-vs-practice article] demonstrates empirically that a model can _recognise_ a term yet silently substitute or confabulate when asked to _apply_ it. The viability test checks whether naming the anchor actually reshapes the output.
+
+=== The Before/After Test
+
+Give a model a task _without_ the anchor term, then the _same_ task _with_ the anchor. Compare structure:
+
+[source]
+----
+# Without anchor:
+Specify what an online shop must do when a customer places an order.
+
+# With anchor:
+Using <your anchor>, specify what an online shop must do when a customer places an order.
+----
+
+If the output structure does not change, the term is decorative — it fails the viability test.
+
+=== Three Failure Modes to Watch For
+
+[cols="1,2,2", options="header"]
+|===
+| Failure Mode | What happens | How to detect
+
+| *Silent substitution*
+| Model delivers content under the requested label, but the content belongs to a different concept.
+| Compare the output against the anchor's canonical definition. Does the structure match?
+
+| *Confabulation*
+| Model invents a confident, internally consistent but fictitious description.
+| Verify key claims (principles, proponents, dates) against the anchor's source material.
+
+| *No structural change*
+| Model "knows" the term but naming it does not reshape the output compared to a generic prompt.
+| Run the before/after test above. If A ≈ B, the anchor is not functional.
+|===
+
+=== Cross-Model Check
+
+Test on at least one _weak_ model (e.g., Haiku-class) and one _strong_ model (e.g., Opus-class). The tier rating reflects the result:
+
+* *★★★ Self-standing* — fires reliably on both weak and strong models.
+* *★★ Needs qualification* — fires only with author/qualifier on weaker models.
+* *★ Descriptive only* — does not reshape output even with qualification → *reject* or move to a *contract*.
+
+=== When to Use a Contract Instead
+
+A term that passes the four quality criteria but fails the viability test belongs in a *contract* (which supplies its own meaning in the prompt), not an anchor (which relies on pre-existing training data). As training data grows, such terms may become viable anchors in future model generations.
+
+See link:docs/training-data-vs-practice.adoc[An Anchor Delivers Only as Far as the Prior Reaches] for the full methodology and worked examples.
+
 == Developer Setup
 
 === Prerequisites

docs/CONTRIBUTING.de.adoc

@@ -54,15 +54,65 @@ Bevor Sie einen Vorschlag machen, testen Sie den Anker mit diesem Prompt in eine
 Welche Konzepte verbindest du mit '<Name Ihres semantischen Ankers>'?
 ----
 
-NOTE: Die Vorlagsvorlage enthält ein Pflichtfeld *LLM Activation Test Result*. Fügen Sie dort Ihre Testausgabe ein — es liefert Reviewern vorab das Precise/Rich/Consistent-Signal.
-
 Bewerten Sie die Antwort:
 
 * *Erkennung:* Erkennt das LLM den Begriff?
 * *Genauigkeit:* Ist die Erklärung korrekt?
 * *Tiefe:* Deckt es mehrere verwandte Konzepte ab?
 * *Spezifität:* Ist der Umfang gut definiert?
 
+== Viability-Test — Does the Anchor Deliver?
+
+Erkennung allein macht keinen viablen Anchor. Der link:docs/training-data-vs-practice.adoc[training-data-vs-practice-Artikel] zeigt empirisch, dass ein Modell einen Begriff _erkennen_ und dennoch bei der _Anwendung_ Silent Substitution oder Confabulation zeigen kann. Der Viability-Test prüft, ob das Benennen des Anchors die Ausgabe tatsächlich verändert.
+
+=== Der Before/After-Test
+
+Geben Sie einem Modell eine Aufgabe _ohne_ den Anchor-Term, dann _dieselbe_ Aufgabe _mit_ dem Anchor. Vergleichen Sie die Struktur:
+
+[source]
+----
+# Ohne Anker:
+Spezifizieren Sie, was ein Online-Shop tun muss, wenn ein Kunde eine Bestellung aufgibt.
+
+# Mit Anker:
+Verwenden Sie <Ihren Anker>, um zu spezifizieren, was ein Online-Shop tun muss, wenn ein Kunde eine Bestellung aufgibt.
+----
+
+Wenn sich die Ausgabestruktur nicht ändert, ist der Term dekorativ — er besteht den Viability-Test nicht.
+
+=== Drei Failure Modes
+
+[cols="1,2,2", options="header"]
+|===
+| Failure Mode | Was passiert | Wie erkennen
+
+| *Silent Substitution*
+| Modell liefert Inhalt unter dem angefragten Label, aber der Inhalt gehört zu einem anderen Konzept.
+| Ausgabe gegen die kanonische Definition des Anchors prüfen. Stimmt die Struktur überein?
+
+| *Confabulation*
+| Modell erfindet eine überzeugt wirkende, intern konsistente aber fiktive Beschreibung.
+| Zentrale Behauptungen (Prinzipien, Proponenten, Jahreszahlen) gegen Quellmaterial verifizieren.
+
+| *No Structural Change*
+| Modell "kennt" den Term, aber das Benennen verändert die Ausgabe nicht gegenüber einem generischen Prompt.
+| Before/After-Test oben durchführen. Wenn A ≈ B, ist der Anker nicht funktional.
+|===
+
+=== Cross-Model-Check
+
+Auf mindestens einem _schwachen_ Modell (z.B. Haiku-Klasse) und einem _starken_ Modell (z.B. Opus-Klasse) testen. Das Tier-Rating spiegelt das Ergebnis:
+
+* *★★★ Self-standing* — feuert zuverlässig auf schwachen und starken Modellen.
+* *★★ Needs qualification* — feuert nur mit Autor/Qualifier auf schwächeren Modellen.
+* *★ Descriptive only* — verändert Ausgabe nicht einmal mit Qualifikation → *ablehnen* oder in einen *Contract* überführen.
+
+=== Wann stattdessen einen Contract verwenden
+
+Ein Term, der die vier Qualitätskriterien besteht aber den Viability-Test nicht, gehört in einen *Contract* (der seine eigene Bedeutung im Prompt mitliefert), nicht in einen Anchor (der auf vorhandene Trainingsdaten angewiesen ist). Wenn Trainingsdaten wachsen, können solche Terme in zukünftigen Modellgenerationen viable Anchors werden.
+
+Siehe link:docs/training-data-vs-practice.adoc[An Anchor Delivers Only as Far as the Prior Reaches] für die vollständige Methodik und Worked Examples.
+
 == Wie man einen neuen Anker vorschlägt
 
 Wir verwenden einen *automatisierten Workflow mit GitHub Copilot* zur Validierung und Anreicherung von Vorschlägen:
@@ -74,7 +124,6 @@ Klicken Sie auf die btn:[Neuen Anker vorschlagen] Schaltfläche auf der https://
 *Alles, was Sie angeben müssen:*
 
 * Der Begriff oder Konzeptname
-* Ein LLM-Aktivierungstestergebnis (Pflichtfeld)
 * (Optional) Warum Sie denken, dass es wertvoll wäre
 
 === Schritt 2: Copilot-Validierung
@@ -140,6 +189,15 @@ Jeder Anker wird als AsciiDoc-Datei mit Metadaten-Attributen gespeichert:
 * `:tags:` - Schlüsselwörter für die Suche (optional, aber empfohlen)
 * `:related:` - Verwandte Anker-IDs (optional)
 
+*Kritik und Aktueller Stand (Recherche verpflichtend, Sektion bei Fund):*
+
+Der Katalog ist ein Begriffslexikon, keine Empfehlungsliste — Aufnahme bedeutet, dass der Begriff als präziser Pointer funktioniert, nicht dass wir die Praxis empfehlen. Recherchiere für jeden neuen Anker, ob dokumentierte Kritik oder Drift existiert, und halte den Befund als Sektion fest:
+
+* `== Kritik` — die Methode selbst ist umstritten. Nur benannte, zitierfähige Kritik (Kritiker + verlinkte Quelle), nie Stimmungen wie „nutzt niemand mehr". Die Sektion referiert den Diskurs, sie urteilt nicht. Nennt der Diskurs Alternativen, nenne sie mit.
+* `== Aktueller Stand` — die Methode steht, aber Trainingsdaten-Prior und Gegenwart sind auseinandergelaufen: Es gibt eine neuere Edition (nenne die Edition, auf die der Prior vermutlich zeigt), einen Nachfolger, oder die Verbreitung ist abgeebbt.
+
+Verifiziere jede verlinkte Quelle vor dem Commit durch tatsächlichen Abruf. Findet die Recherche nichts Zitierfähiges, entfallen beide Sektionen — eine leere Sektion ist Rauschen. Hintergrund: die Katalog-Triage in https://github.com/LLM-Coding/Semantic-Anchors/issues/603[#603].
+
 == Gegenbeispiele
 
 Dies sind *KEINE* semantischen Anker:
@@ -187,52 +245,6 @@ Anker sind mit beruflichen Rollen getaggt, um relevante Inhalte zu filtern:
 . Team Lead / Engineering Manager
 . Educator / Trainer
 
-== Issue-Titel-Konvention
-
-Alle Issues sollten einem konsistenten `[Typ]: <Name>` Titelformat folgen. Dies macht Filtern, Suchen und Triagieren wesentlich einfacher.
-
-=== Anerkannte Prefixe
-
-[cols="1,2,1"]
-|===
-| Prefix | Verwendet für | Quelle
-
-| `[Anchor Proposal]:`
-| Vorschläge für neue semantische Anker
-| Issue-Template
-
-| `[Contract Proposal]:`
-| Vorschläge für neue semantische Contracts
-| Issue-Template
-
-| `[Improve]:`
-| Verbesserungen an bestehenden Ankern
-| Issue-Template
-
-| `[Bug]:`
-| Fehlermeldungen
-| Issue-Template
-
-| `[Process Proposal]:`
-| Änderungen an Projektprozessen
-| Issue-Template
-
-| `[Feature]:`
-| Feature-Anfragen
-| Frei formuliert
-
-| `EPIC:`
-| Tracking-Issues für größere Initiativen
-| Frei formuliert
-|===
-
-=== Richtlinien
-
-* *Verwenden Sie das Issue-Template*, wann immer eines existiert — das Prefix wird automatisch gesetzt.
-* *Frei formulierte Issues* (kein passendes Template) sollten manuell eines der anerkannten Prefixe verwenden.
-* *Nur zukünftig anwenden* — geschlossene Issues nicht rückwirkend umbenennen.
-* *EPICs* verwenden das bloße `EPIC:` Prefix ohne Klammern als anerkannte Ausnahme.
-
 == Verhaltenskodex
 
 * Seien Sie respektvoll und konstruktiv in Diskussionen

docs/rejected-proposals.adoc

@@ -9,8 +9,8 @@ Understanding why proposals are rejected helps contributors submit better propos
 Structurally unsuitable::
 The term is too vague, has no defined methodology, or is a pure instruction rather than a concept. Fails the link:#/about[Precise] and/or link:#/about[Rich] criteria.
 
-Not in training data::
-A legitimate concept or framework, but not established enough in LLM training data to reliably activate the right knowledge. Fails the link:#/about[Consistent] criterion.
+Insufficient training-data density::
+The term is recognised (models can talk _about_ it) but does not reliably _activate_ the concept in outputs. Naming it does not structurally change the output compared to a generic prompt, or triggers silent substitution / confabulation on weaker models. Terms in this category may become viable anchors as training data grows — consider a link:#/contracts[contract] for now. See link:#/training-data-vs-practice[An Anchor Delivers Only as Far as the Prior Reaches] for the empirical methodology. Fails the viability test.
 
 Too niche::
 A real methodology but too specialized for reliable activation across different LLMs and contexts. Fails the link:#/about[Consistent] and/or link:#/about[Rich] criteria.
@@ -42,7 +42,7 @@ A real methodology but too specialized for reliable activation across different
 *Now available as link:#/contracts[Semantic Contract]*: "Layer Boundaries".
 
 | *MIRRR UX Framework* (https://github.com/LLM-Coding/Semantic-Anchors/issues/150[#150])
-| Not in training data
+| Insufficient training-data density
 | A real UX framework with defined methodology, but not widely enough documented for LLMs to reliably recognize it and activate the correct concepts.
 
 | *YOLO* (https://github.com/LLM-Coding/Semantic-Anchors/issues/443[#443])

website/public/CONTRIBUTING.de.adoc

@@ -61,6 +61,58 @@ Bewerten Sie die Antwort:
 * *Tiefe:* Deckt es mehrere verwandte Konzepte ab?
 * *Spezifität:* Ist der Umfang gut definiert?
 
+== Viability-Test — Does the Anchor Deliver?
+
+Erkennung allein macht keinen viablen Anchor. Der link:docs/training-data-vs-practice.adoc[training-data-vs-practice-Artikel] zeigt empirisch, dass ein Modell einen Begriff _erkennen_ und dennoch bei der _Anwendung_ Silent Substitution oder Confabulation zeigen kann. Der Viability-Test prüft, ob das Benennen des Anchors die Ausgabe tatsächlich verändert.
+
+=== Der Before/After-Test
+
+Geben Sie einem Modell eine Aufgabe _ohne_ den Anchor-Term, dann _dieselbe_ Aufgabe _mit_ dem Anchor. Vergleichen Sie die Struktur:
+
+[source]
+----
+# Ohne Anker:
+Spezifizieren Sie, was ein Online-Shop tun muss, wenn ein Kunde eine Bestellung aufgibt.
+
+# Mit Anker:
+Verwenden Sie <Ihren Anker>, um zu spezifizieren, was ein Online-Shop tun muss, wenn ein Kunde eine Bestellung aufgibt.
+----
+
+Wenn sich die Ausgabestruktur nicht ändert, ist der Term dekorativ — er besteht den Viability-Test nicht.
+
+=== Drei Failure Modes
+
+[cols="1,2,2", options="header"]
+|===
+| Failure Mode | Was passiert | Wie erkennen
+
+| *Silent Substitution*
+| Modell liefert Inhalt unter dem angefragten Label, aber der Inhalt gehört zu einem anderen Konzept.
+| Ausgabe gegen die kanonische Definition des Anchors prüfen. Stimmt die Struktur überein?
+
+| *Confabulation*
+| Modell erfindet eine überzeugt wirkende, intern konsistente aber fiktive Beschreibung.
+| Zentrale Behauptungen (Prinzipien, Proponenten, Jahreszahlen) gegen Quellmaterial verifizieren.
+
+| *No Structural Change*
+| Modell "kennt" den Term, aber das Benennen verändert die Ausgabe nicht gegenüber einem generischen Prompt.
+| Before/After-Test oben durchführen. Wenn A ≈ B, ist der Anker nicht funktional.
+|===
+
+=== Cross-Model-Check
+
+Auf mindestens einem _schwachen_ Modell (z.B. Haiku-Klasse) und einem _starken_ Modell (z.B. Opus-Klasse) testen. Das Tier-Rating spiegelt das Ergebnis:
+
+* *★★★ Self-standing* — feuert zuverlässig auf schwachen und starken Modellen.
+* *★★ Needs qualification* — feuert nur mit Autor/Qualifier auf schwächeren Modellen.
+* *★ Descriptive only* — verändert Ausgabe nicht einmal mit Qualifikation → *ablehnen* oder in einen *Contract* überführen.
+
+=== Wann stattdessen einen Contract verwenden
+
+Ein Term, der die vier Qualitätskriterien besteht aber den Viability-Test nicht, gehört in einen *Contract* (der seine eigene Bedeutung im Prompt mitliefert), nicht in einen Anchor (der auf vorhandene Trainingsdaten angewiesen ist). Wenn Trainingsdaten wachsen, können solche Terme in zukünftigen Modellgenerationen viable Anchors werden.
+
+Siehe link:docs/training-data-vs-practice.adoc[An Anchor Delivers Only as Far as the Prior Reaches] für die vollständige Methodik und Worked Examples.
+
 == Wie man einen neuen Anker vorschlägt
 
 Wir verwenden einen *automatisierten Workflow mit GitHub Copilot* zur Validierung und Anreicherung von Vorschlägen: