Meta3.0 Architecture

Stand: 2026-06-15

Ziel

Meta3.0 soll eine sehr grosse, ueber Nacht laufende Analyse der bisherigen Agenten-/Session-Historie vorbereiten. Der Ordner soll Anforderungen aufnehmen, Runs reproduzierbar manifestieren und Batch-/Budgetplanung sichtbar machen.

Meta3.0 ist nicht "Meta2 nochmal". Meta2.0 ist die Datenmaschine: Inventory, Layer-1-Digests, Backfill, stabile Qwen-Batches. Meta3.0 ist der bessere Versuchsaufbau darueber: kontrollierte Fragelogik, Evidenzpflicht, Gegenbeweis-Suche, Validitaets-Gates und owner-faehige Verdichtung.

Nicht-Ziel

Keine unkontrollierten API-Calls beim Setup.
Kein Legacy-Frage-Fanout ueber alle Rohsessions.
Keine Edits in globalen Profilen, MCP-Configs, Registries oder anderen Projekten.
Keine Secrets in Dateien.

Datenlinie

Meta2.0 Layer 0 Inventory
  -> Meta2.0 Layer 1 session_digests.jsonl
  -> Meta3.0 experiment design
  -> Meta3.0 question set + claim/evidence contract
  -> Meta3.0 batch plan + validity gates
  -> spaeter: Layer 2/3 Antworten mit Evidenz, Gegenbelegen und Owner-Fazit

Meta3.0 liest vorhandene Meta2.0-Artefakte read-only:

/home/smlflg/Projekte/Meta2.0/data/session_inventory.json
/home/smlflg/Projekte/Meta2.0/data/layer1/session_digests.jsonl
/home/smlflg/Projekte/Meta2.0/data/layer1/audit.json

Run-Vertrag

Jeder Run bekommt einen eigenen Ordner:

runs/<timestamp>_<slug>/
  manifests/
    run_manifest.json
    batch_plan.json
  state/
  outputs/
  logs/
  tmp/

run_manifest.json ist die Wahrheit fuer:

welche Fragen,
welches Profil,
welche Quellen,
welche Env-Variablen vorhanden waren,
welche Sicherheitsflags aktiv waren.

batch_plan.json ist die Wahrheit fuer:

wie viele Sessions/Digests aktuell existieren,
ob diese Zahl aus Audit-Unique-Digests oder rohen JSONL-Zeilen stammt,
wie viele Layer-1 Backfill-Calls geschaetzt werden,
wie viele Frage-/Synthese-Calls geschaetzt werden,
welche Gates vor dem Start noch offen sind.

Meta3 Improvement Contract

Ein Meta3-Run darf nur als Verbesserung gegenueber Meta2 gelten, wenn er mehr leistet als "mehr Calls":

Stratifizierte Evidenz statt blinder Masse. Antworten muessen Quellen ueber Sessions, Zeitraeume und Tool-Familien streuen, damit 954 Codex-Files nicht automatisch alle anderen Spuren ueberrollen.
Claim Ledger statt Essay. Jede starke Aussage braucht mindestens eine positive Evidenz, eine Unsicherheit oder ein Gegenbeispiel und eine Rueckfuehrung auf konkrete Artefakte.
Gegenbeweis-Pflicht. Fuer jede Hauptthese wird aktiv nach Sessions gesucht, die sie schwaechen. Fehlt Gegenbeweis-Suche, ist das Ergebnis nur Rohsynthese.
Validitaet vor Score. Kein "finales Ergebnis", wenn Quellenabdeckung, Run-Manifest, Modell-/Prompt-Versionen, Call-Ledger oder Output-Artefakte fehlen.
Fragen als Graph, nicht Liste. Q01-Q09 erzeugen Zwischenbefunde, Konflikte und offene Wahrheiten; Q10 darf erst daraus verdichten.
Owner-Fazit statt Agentenlarm. Jede Antwort endet mit einer kanonischen These, Grenzen der Aussage und einem naechsten menschlich sinnvollen Schritt.

Der maschinenlesbare Vertrag steht in config/experiment_design.json. Die blockierende Eval-Spezifikation steht in docs/evals/EVAL_meta3_improvement_over_meta2.md.

Call-Strategie

Der grosse Wert kommt nicht aus 10 Mio Fragen gegen Rohdaten, sondern aus einmaligem, question-agnostic Digesting. Danach duerfen Fragen gegen die verdichteten Layer laufen.

Meta3 nutzt die 10-Mio-Call-Grenze als Budget-Oberkante, nicht als Startbefehl. Die intelligente Reihenfolge ist:

kleine Kalibrierung gegen vorhandene Digests,
Abgleich der Antwortqualitaet gegen den Improvement Contract,
kontrollierter Layer-1-Backfill,
erst danach breite Frage- und Synthese-Laeufe.

Startregel:

sichere Meta2-Einstellung respektieren: batch_size=3, concurrency=2.
nur hochdrehen, wenn Fehlerrate, 429-Rate und Datenqualitaet stabil bleiben.