Partitur-Nachbearbeitung

TippPartitur in einem Satz

Die Partitur ist ein formalisierter Aktionsplan, dessen Ausführung das vollständig transkribierte Dokument mit semantischer Struktur anreichert: Bibliographiedaten, Belegposten, Regest — je nach Dokumenttyp.

Nach OCR und PDAI-Ablage steht der Rohtranskript fest. Die Partitur-Nachbearbeitung wertet diesen Transkript aus und ergänzt die Ablage um semantisch strukturierte Metadaten. Sie läuft nicht auf dem Erfassungsgerät, sondern im lokalen Netz über den ai-agent-orchestrator.

Der Begriff „Partitur” (aus dem Musikbereich: der vollständige mehrstimmige Notenplan) beschreibt hier einen deklarierten Ablaufplan für einen KI-Agenten: eine YAML-Datei, die Eingaben, Verarbeitungsschritte, Modellauswahl und Ausgabeformat definiert. Die Ausführung der Partitur ist Regelfolgen im Sinne Wittgensteins (PU 185–202): eine Praxis, die den Plan instanziiert — keine bloße Textinterpretation des YAML.

1 Verbindung zum Orchestrator

PartiturClient stellt eine HTTP-Verbindung zum ai-agent-orchestrator auf Port 5401 her. Der Standardendpunkt ist http://127.0.0.1:5401.

Die relevanten Endpunkte:

Endpunkt Methode Funktion
/api/run/partitur GET Liste der verfügbaren Partitur-Pfade
/api/run POST (synchron) Partitur-Lauf mit Eingaben starten (kurze Scores)
/api/run/async POST Asynchroner Partitur-Start; gibt job_id zurück
/api/run/async/{job_id} GET Polling: Status und Ergebnis des laufenden Jobs

PartiturClient nutzt für Extended OCR den asynchronen Pfad: POST → polling-Schleife alle 5 s → Ergebnis nach Abschluss. Die App-interne Timeout-Grenze ist 3600 s (Job-TTL im Orchestrator).

Ein Lauf gibt zurück: run_id, partitur_id, succeeded (Boolean), grade (Bewertungsstring), summary (Zusammenfassung) und die strukturierten output-Daten.

Die URL ist über den Standard-Einstellungsschlüssel FamulusReproOrchestratorURL in UserDefaults änderbar.

2 Die Partitur-Scores von Famulus Repro

Famulus Repro verwendet sechs Partitur-Scores, aufgeteilt nach Dokumentmodus. Im Inspektor-Panel werden sie nach Modus gefiltert.

Partitur: repro_extended_ocr_agent

Kern-OCR für Buchseiten: Bild + Transkript → DTD-konformes Buch-XML.

  • Modell: gemini-3.8-flash (Batch-Standard), glm-5.3-flash:cloud (Sync-Fallback)
  • Eingabe: Verarbeitetes Seitenbild + Vision-Rohtranskript
  • Ausgabe: page_NNN.ext.xml nach repro_page.dtd (Fließtext, Überschriften, Figuren, Tabellen, Fußnoten)
  • Validierung: DTD-Validierung + Reparatur-Sweep in validate.py

Partitur: repro_receipt_ocr_agent

Extended OCR für Belege: Bild + Transkript → DTD-konformes Beleg-XML + JSON.

  • Modell: gemini-3.8-flash Batch
  • Eingabe: Verarbeitetes Belegbild + Vision-Rohtranskript
  • Ausgabe: <stem>.ext.xml nach repro_receipt.dtd + <stem>.receipt.json
  • DTD-Schema: Händler, Adresse, Positionen, Steuern, Zahlung, TSE, Reise, Treibstoff, Parken, Apotheke

Partitur: repro_receipt_agent

Schnelle Belegfeld-Extraktion für sofortige Ordnerumbenennung (kein Bild, nur Transkript).

  • Modell: fasttext (Apple Foundation Model, on-device)
  • Eingabe: Vision-OCR-Transkript
  • Ausgabe: [klasse]-Firma-Datum-Betrag-Währung-Stem für Ordnerumbenennung

Partitur: repro_book_agent

Bibliographiedaten und Seitenstruktur aus mehrseitigem Buchscan.

  • Modell: glm-5.3-flash:cloud (via Ollama)
  • Eingabe: Alle Seiten-Transkripte + Kolumnentitel-Sequenz
  • Ausgabe: Autor, Titel, Jahr, Verlag, Seitenzuordnung, Kolumnentitel-Korrekturen

Partitur: repro_booktype_agent

Erkennt das Buchformat und erstellt ein OCR-Overlay für strukturierte Extraktion.

  • Modell: fasttext → gemini-3.8-flash (Pilot-OCR)
  • Eingabe: Seitenbilder + Transkripte
  • Ausgabe: BookType-JSON-Overlay mit DTD-Grammatik, Seiten-Konventionen, Pilot-Verdict

Partitur: repro_archival_agent

Regest für historische Dokumente (Briefe, Urkunden, Akten).

  • Modell: fasttext (Apple Foundation Model)
  • Eingabe: OCR-Transkript
  • Ausgabe: EDTF-Datum, Absender, Empfänger, Personen, Ortsnamen, Kurzregest (1–3 Sätze)

3 Auswahl der Partitur im Inspektor

Der Standardscore hängt vom Dokumentmodus ab:

  • Buchmode: repro_extended_ocr_agent für OCR, repro_book_agent für Bibliographie
  • Einzelblattmode: repro_receipt_ocr_agent (Extended), repro_receipt_agent (Schnell)

Über den Schalter “Alle Partituren” sind alle weiteren Scores aus dem agent-store/ abrufbar.

4 Das partitur.json-Artefakt

Der Lauferfolg und alle Ausgaben des Partitur-Agenten werden in partitur.json im PDAI-Dokumentordner gespeichert und in das document.json-Register eingetragen. Zusätzlich ergänzt PartiturClient jedes page_NNN.json mit einem partitur-Feld, das die Partitur-Ergebnisse für die jeweilige Seite enthält.

partitur.json — Ergebnis des repro_book_agent-Laufs

{
  "run_id": "run-2026-09-03-08-42-17",
  "partitur_id": "repro_book_agent",
  "succeeded": true,
  "grade": "EXCELLENT",
  "summary": "Bibliographiedaten vollständig extrahiert. Seitenzuordnung rekonstruiert.",
  "output": {
    "author": "Graßhoff, Gerd",
    "title": "The History of Ptolemy's Star Catalogue",
    "year": 1990,
    "publisher": "Springer",
    "folder_name": "Grasshoff_1990_History_Ptolemy_Star_Catalogue",
    "pages": [
      {"scan_index": 1, "printed_page": "iv", "running_head": "Preface"},
      {"scan_index": 2, "printed_page": "v",  "running_head": "Preface"}
    ]
  }
}

5 Fehlerbedingungen

PartiturClient unterscheidet drei Fehlerfälle:

  • unreachable: Orchestrator antwortet nicht auf Port 5401 — der Dienst ist nicht gestartet.
  • badStatus: HTTP-Fehlercode vom Orchestrator mit Antworttext.
  • emptyTranscript: Kein OCR-Text vorhanden. Die Partitur kann nicht starten, weil sie keinen Eingabetext hat; der Nutzer muss zuerst Seiten aufnehmen.

In allen drei Fällen erscheint im Backstage eine präzise Fehlermeldung in natürlicher Sprache — keine technischen Statuscodes.