---
name: av-knowledge-catalog
description: Bewertet die Readiness-Dimension „Knowledge-Catalog Readiness" — stellt das Unternehmen einen verifizierten, maschinenlesbaren Datensatz bereit, den KI-/Agent-Systeme direkt konsumieren können (Data-Era statt Crawl-Era, A2A-bereit)? Nutzen, wenn im Readiness-Audit (v3, 8 Dimensionen) die agentische Datenbereitstellung / der Knowledge-Catalog einer Marken-Website bepunktet werden soll.
---

> **EVN:** Dieser Skill misst die Eigenschaft (Stellhebel) **„Knowledge-Catalog Readiness"** → trägt zum Vorteil **agentische Auffindbarkeit** bei → Nutzen **direkt konsumierbarer, verifizierter Marken-Datensatz für KI-Agenten**.

# av-knowledge-catalog — Dimension „Knowledge-Catalog Readiness" (8. Achse, v3)

Bewertet die **achte Dimension** des Search-&-AI-Readiness-Audits (v3-Modell). Leitfrage: *Liegt das Markenwissen als verifizierter, strukturierter Datensatz vor, den ein KI-/Agent-System direkt konsumieren kann — statt nur als zu crawlende Website?*

**Status: Agentic-Modul — emerging / experimental / Agentic-Readiness-Hypothese.** Kundenseitig ist diese Achse das **optionale Agentic-Modul neben den 7 Kern-Dimensionen** — bewusst NICHT als etablierte, gleichwertige Standard-Dimension positioniert (intern wird 8-achsig gemessen). Sie bewertet eine Zukunfts-Readiness, deren praktischer Nutzen noch nicht empirisch belegt ist.

Hintergrund — **prognostische These, kein etablierter Ist-Zustand**: die erwartete Verschiebung von der **Crawl-Era** (Suchsysteme crawlen HTML und sourcen daraus) zur **Data-Era** (Agenten konsumieren einen verifizierten Datensatz; A2A-Interaktion Agent↔Agent). Ein „Knowledge Catalog" wäre genau dieser verifizierte Datensatz — die agentische Entsprechung zur Website als Front-End. Fachlicher Anker dieser These ist u. a. Googles **„Agentic Resource Discovery"-Spezifikation (Google-Spez)**: `ai-catalog.json` als auffindbarer Katalog von Fähigkeiten (MCP-Server, A2A-Agenten, OpenAPI-Tools). Ob und wann sich diese Data-Era-Erwartung breit durchsetzt, ist offen — die Achse misst die Vorbereitung darauf, nicht einen heutigen Sichtbarkeits-Hebel.

Score 0–100 als gewichtete Summe aus 4 Sub-Checks, jeder gegen die 0/25/50/75/100-Rubrik.

## Wann nutzen

- Wenn ein Readiness-Audit (v3, 8 Dimensionen) läuft und die Knowledge-Catalog-/Data-Era-Readiness bepunktet werden muss.
- Wenn geprüft werden soll, ob eine Marke A2A-/Agent-bereit ist (maschinenlesbarer Datensatz, Transactability, Feed/API).

## Methode — Sub-Checks und Gewichte

1. **JSON-LD-Vollständigkeit & -Vielfalt** — 30 %
   Deckt das Schema die Kern-Entitäten ab? Organization/LocalBusiness, Product/Service/Offer, FAQPage, `sameAs`-Entitäts-Graph. Mehrere passende Typen, konsistent über Templates.
2. **Maschinenlesbare Endpoints** — 25 %
   `llms.txt`, Feed/RSS/Atom, sichtbare API / OpenAPI / `/.well-known/ai-plugin.json` / GraphQL — Wege, auf denen ein Agent strukturierte Daten direkt zieht statt HTML zu parsen.
3. **Transactability / Agentic-Booking** — 25 %
   `schema.org` `potentialAction` (Order/Reserve/Schedule), erkennbare Online-Scheduling-/Booking-Integration. **Code-Signal first** — gemessen wird die maschinenlesbare *Möglichkeit* zu transagieren, NICHT ein realer Abschluss.
4. **Maschinenlesbare Preis-/FAQ-/Policy-Daten** — 20 %
   `Offer.price`/`priceCurrency`, FAQPage, Policy-/Versand-/Rückgabe-Markup. Branchen-gewichtet (`pricing_transparency_weight` in method_config): hoch bei Shop/Service, niedrig bei Portal/Medien.

`Knowledge-Catalog Score = Σ (Sub-Score × Gewicht)`

Score-Anker: 0 = kein maschinenlesbarer Datensatz · 25 = vereinzeltes Markup, nicht konsumierbar · 50 = teils, lückenhaft/inkonsistent · 75 = stark, kleine Lücken · 100 = vollständiger, verifizierter, agent-konsumierbarer Katalog. **Nie 100 nur weil ein Schema-Block existiert.**

## Inputs — deterministische Code-Signale (Faktenbasis)

Aus `~/audit-app/ai-visibility-audit/src/website_scorer.py` → `_catalog_signals(html)` (läuft NUR, wenn die geladene Config die Achse `knowledge_catalog` kennt — Isolation gegen die 7-Achsen-Live-Baseline):

- `kc_jsonld_block_count`, `kc_jsonld_types` (Liste der erkannten `@type`)
- `kc_has_organization`, `kc_has_product_or_service`, `kc_has_faqpage`, `kc_has_sameas`
- `kc_has_potential_action` (Transactability), `kc_has_offer_price`
- `kc_has_feed` (RSS/Atom), `kc_has_api_hint` (openapi/ai-plugin/graphql/api)
- ergänzend aus `_detect_signals`: `has_llms_txt`, `has_sitemap`

Der LLM bewertet auf dieser Faktenbasis nur **Vollständigkeit/Qualität/Konsistenz** — die Existenz-Fakten selbst kommen aus Code (reproduzierbar, kein Halluzinations-Spielraum).

## Tier-Logik — Cold vs Connected/Paid

- **Cold Audit** (kostenlos, Sales-Prozess): nur öffentliche Code-Signale → **Confidence B**. Dient als Sales-Hook („Ihre Marke hat keinen konsumierbaren Knowledge-Catalog — im Crawl-Era-Modus gefangen").
- **Connected/Paid Audit** (Kundenanbindung): zusätzlich GSC verified-domain-Status, Discoverability-API-Anbindung, echte Katalog-/Feed-Verifikation → **Confidence A**.

## Output-Format (JSON)

```json
{
  "axis_key": "knowledge_catalog",
  "score": 0,
  "sub_signals": {
    "jsonld_completeness": {"score": 0, "weight": 30, "reason": "", "evidence_label": "VERIFIED"},
    "machine_endpoints":   {"score": 0, "weight": 25, "reason": "", "evidence_label": "VERIFIED"},
    "transactability":     {"score": 0, "weight": 25, "reason": "", "evidence_label": "VERIFIED"},
    "machine_pricing_faq": {"score": 0, "weight": 20, "reason": "", "evidence_label": "VERIFIED"}
  },
  "confidence": "B",
  "tier": "cold",
  "measured_at": "YYYY-MM-DD"
}
```

Jede `reason` ist konkret und stützt sich auf die erkannten `kc_*`-Signale, keine Bauch-Bewertung.

## Guardrails

- **Vorhandensein ≠ Garantie:** Ein Knowledge-Catalog / `potentialAction` / Feed ist ein **Readiness-Sub-Signal**, KEINE Garantie für Agent-Inklusion, KI-Sichtbarkeit oder eine tatsächliche A2A-Transaktion.
- **Emerging-Modul, nicht Standard-Dimension:** Kundenseitig immer als optionales Agentic-Modul (experimental / Agentic-Readiness-Hypothese) neben den 7 Kern-Dimensionen ausweisen; die Data-Era-Story als prognostische These kennzeichnen, nicht als etablierte SEO-Grundlage verkaufen. „Agentic Resource Discovery" nur als Googles Spezifikation referenzieren (Namenskollision mit dem früheren Audit-Arbeitstitel vermeiden).
- **Transactability = Code-Signal first:** gemessen wird die maschinenlesbare *Möglichkeit*. Ein echter A2A-/Booking-Probelauf (Agent stößt real eine Buchung an) ist bewusst **Backlog** (fragil + ethisch heikel) — beide Tiers messen vorerst nur das Code-Signal.
- **Keine Doppelmessung:** Strukturierte-Daten-*Validität* für Crawl/Index bleibt in `av-tech-discoverability`; hier zählt die *Vollständigkeit/Konsumierbarkeit als Datensatz*. Die maschinenlesbare `potentialAction` ist aus `av-actionability` hierher gewandert (v3-Rebalance) — dort nicht erneut werten.
- Fehlt der Seitenzugriff: `MISSING_DATA` / „not measured" statt 0; Confidence auf C.
- Evidenz-Label je Sub-Signal (MEASURED/VERIFIED/HYPOTHESIS/MISSING_DATA), Mess-Datum + Tier immer ausweisen.

## Verwandte Skills

- **av-website-scorer** — ruft diese Achse als 6. Website-Achse mit auf (v3).
- **av-tech-discoverability** — misst Strukturdaten-*Validität* (Abgrenzung: hier *Vollständigkeit/Konsumierbarkeit*).
- **av-actionability** — Mensch-seitige Handlungsfähigkeit (Abgrenzung: hier maschinenlesbare `potentialAction`).
- **av-guardrails** — erzwingt Evidenz-Labels und Truth-Rules.
- **av-gap-strategist** — nutzt den Dimensions-Score für die Gap-Strategie.

Stand: 2026-07-10 (Feedback-Rework v2.1)