SkillSafe

Warum zwei Stufen nötig sind, zeigt der mitgelieferte Beispielbaum. Auf die Anfrage „Minderung Mangel Wohnung" liefert die erste Stufe das Seerecht mit 78 Punkten vor dem Mietrecht mit 60, weil beide Katalogtexte absichtlich fast gleich klingen. Die zweite Stufe liest den tatsächlichen Satzbestand und dreht das Verhältnis auf 460 zu 152. Der Katalogtext ist ein schwaches Signal, der Bestand dahinter das starke. Ein Dokument, in dem kein einziger Anfragebegriff als ganzes Wort vorkommt, fällt heraus, egal wie gut sein Katalogeintrag aussah.

Findet die zweite Stufe nichts, kommt nichts zurück. Kein alphabetischer Notnagel, kein bester Fehltreffer, stattdessen eine Meldung, die sagt, was zu tun ist. Ein plausibel aussehender Fehltreffer ist teurer als gar kein Treffer, weil er nicht als Fehler auffällt. Abgeglichen wird ausschließlich an Wortgrenzen, deshalb findet „himmel" auch kein „schimmel".

Eine Zusage verschiebt sich damit, und das gehört deutlich gesagt: „Kein Netzwerk im Skill" gilt jetzt für den regulären Abfrageweg statt absolut. Ohne --extern verlässt kein Byte den Skill-Ordner, weder zur Festplatte noch ins Netz. Mit --extern liest der Tresor ausschließlich aufgeführte Ziele, unter festem Präfix, mit Zeit-, Größen- und Weiterleitungsgrenzen. SKILLSAFE_OFFLINE=1 schaltet jeden Abruf hart ab, noch vor dem ersten Socket; die Prüfkette läuft damit netzfrei. Protokoll und Grenzen stehen in references/externe-quellen.md.

validate: 0 Fehler, 0 Warnungen — 5 Seiten, 26 Claims, 4 Quellen.

── doctor: Gesamtdiagnose ─────────────────────────────────────
── Prüfsummen ─────────────────────────────────────────────────
verify: 37 Dateien unverändert — Stand = Manifest.
── Zusammenfassung ────────────────────────────────────────────
doctor: 0 Fehler, 0 Warnungen, 0 Hinweise — 6 Seiten / 28 Claims / 4 Quellen.

{
  "schema": "skillsafe.query/v1",
  "state": "candidates_found",
  "retrieval": "hybrid-local/v1",
  "coverage": {"semantic_coverage": "not_assessed"},
  "concepts": {"matched": [{"id": "B-0001", "preferred": "Open Knowledge Format"}]},
  "evidence": [
    {"claim_id": "C-0001", "page_status": "veraltet", "signals": ["page_status:veraltet", "trust_tier:unverified"], "source": {"id": "S-0001", "trust": "T2"}},
    {"claim_id": "C-0301", "page_status": "aktiv", "signals": ["trust_tier:unverified"], "source": {"id": "S-0004", "trust": "T1"}}
  ]
}

{
  "schema": "skillsafe.query/v1",
  "state": "no_candidates",
  "coverage": {"semantic_coverage": "not_assessed"},
  "fallback": {
    "exhaustive_review_required": true,
    "page_paths": [
      "knowledge/demo-okf/fakten.md",
      "knowledge/demo-okf/llm-wiki-muster.md",
      "knowledge/demo-okf/okf-v02.md",
      "knowledge/demo-okf/okf.md",
      "knowledge/demo-okf/ontologie-strategie.md"
    ]
  },
  "evidence": []
}

Der erste Treffer stammt aus der überholten Fassung, und das ist Absicht. Das Ranking bewertet Geltung nicht, es markiert sie mit page_status:veraltet. Welche Fassung maßgeblich ist, entscheidet der Antworten-Workflow anhand der ersetzt-Kante im Graph, und er benennt beide. Verstecken wäre die einfachere, aber unehrliche Lösung.