glpi-neural-brain/WORKFLOW-INTEGRITY-V10.md

Workflow Integrity v10

Ziel

v10 haertet vier Workflowgrenzen, die im Realbetrieb nach v9 sichtbar wurden:

1. Relationsrecherche darf keine ungeprueften Suchtreffer mehr als Graph-Evidenz materialisieren.
2. Der autonome Opportunity-Scanner darf bei ausgeschoepftem Tagesbudget keinen wachsenden Research-Backlog erzeugen.
3. Operational klassifizierte Artikel duerfen bei fehlender operativer Evidenz genau einmal in einen tragfaehigen nicht-operationalen Artikeltyp umgeplant werden, ohne Quality-Gates zu lockern.
4. Mathematische Vector-Reevaluation und sanfte Layout-Relaxation muessen auch bei pausiertem Learning weiterlaufen und ihren effektiven Layoutmodus korrekt melden.

Zusaetzlich werden autonome Research-Gesamtsummen restart-stabil aus SQLite gelesen.

---

1. Thinking Relation Research: Fulltext Evidence Gate v10

Problem in v9

Der aeltere Relation-Research-Pfad behandelte SearXNG-Treffer anders als die neuere Autonomous-/Article-Research-Pipeline. Ein Relation-Planner konnte eine Suchanfrage erzeugen, die interne Graph-IDs statt sichtbarer Fachbegriffe enthielt. Suchtreffer wurden zwar durch Source-/Category-Filter eingeschraenkt, aber nicht einzeln durch einen strikten Fulltext-Evidenzpfad validiert. Wenn der zweite Relationsreview anschliessend die Relation akzeptierte, konnten die erlaubten Suchtreffer dauerhaft als externe Research-Nodes materialisiert werden.

Das war eine stille Graphkontaminationsmoeglichkeit: Die Relation selbst konnte fachlich plausibel sein, waehrend die zugehoerigen Webtreffer fachfremd waren.

v10-Verhalten

Relationsrecherche arbeitet jetzt nach diesem Ablauf:

Relation Planner
    ↓
Research benoetigt?
    ├─ nein → Relation normal bewerten
    └─ ja
         ↓
Query Guard
         ↓
interne Node-ID / Hash / kein fachlicher Titelanker?
         ├─ ja → Query deterministisch aus sichtbaren Labels neu aufbauen
         └─ nein → Planner-Query behalten
         ↓
SearXNG SearchDetailed
         ↓
Thinking Source Scope
         ↓
Snippet Topic Gate
         ↓
max. 4 Fulltext-Fetches
         ↓
Fulltext Topic Guard + Relevance + Source Quality
         ↓
NUR akzeptierte Volltexte
         ↓
zweiter Qwen-Relationsreview
         ↓
Relation akzeptiert?
         ├─ nein → keine Graphmaterialisierung
         └─ ja  → nur akzeptierte Fulltext-Evidence materialisieren

Query Guard

Interne Identifikatoren duerfen nicht in oeffentliche Suchanfragen gelangen.

v10 erkennt insbesondere:

• konkrete Source-/Target-Node-IDs;
• hexadezimale ID-/Hash-artige Tokens mit 20 bis 64 Zeichen;
• generische Planner-Queries ohne einen sinnvollen Begriff aus Source-Label, Target-Label oder Topic-Label.

Bei einem Treffer wird die Query aus menschlich sichtbaren Fachbegriffen neu aufgebaut. Ein Event think.research.query.rebuilt dokumentiert Originalquery, neue Query und Grund.

Fail-closed

Wenn eine Relation explizit externe Fakten benoetigt, gilt in v10:

• Search-/Fetch-Fehler → die beweisabhaengige Relation wird nicht akzeptiert;
• kein einziger Fulltext-Beleg besteht das Evidenzgate → Relation wird nicht akzeptiert;
• zweiter evidenzbasierter Relationsreview scheitert → Relation wird nicht akzeptiert.

Die Tatsache, dass die beiden internen Nodes eine hohe Vektoraehnlichkeit haben, reicht dann nicht aus, um eine als beweisabhaengig geplante Relation trotzdem zu materialisieren.

Ephemeral bis zur Freigabe

SearXNG-Treffer sind nur Kandidaten. Vor einer akzeptierten Relation entstehen daraus keine External Nodes und keine research_evidence-Kanten.

Erst nach erfolgreichem Fulltext-Gate und erfolgreichem Relationsreview werden akzeptierte Belege via addResearch geschrieben. Metadaten enthalten u. a.:

validation_state = relation_fulltext_gate_v10
relevance
source_quality
source_quality_score
assessment_reason

Wenn moeglich wird der akzeptierte Fulltext zusaetzlich im Research-Evidence-Store persistiert und dessen Pfad/Hash am Node hinterlegt.

---

2. Autonomous Research: Budget-aware Queue

Problem in v9

Der Worker respektierte BRAIN_AUTONOMOUS_RESEARCH_MAX_TASKS_PER_DAY, der Opportunity-Scanner konnte aber weiter neue Tasks enqueueen. Bei einem absichtlich kurzen Scanintervall entstand dadurch ein persistenter Backlog, obwohl der Worker fuer den aktuellen UTC-Tag keine weiteren Tasks mehr ausfuehren durfte.

Aehnliche Topics konnten ausserdem durch geaenderte Seed-Mitgliedschaften mehrfach in der Queue liegen.

v10-Budgetmodell

Vor jedem Opportunity-Scan wird die aktuelle Kapazitaet berechnet:

remaining = max_tasks_per_day
          - completed_today_utc
          - active_research_tasks

active_research_tasks umfasst die gesamte vom selben Worker konsumierte aktive Queue:

• queued
• deferred
• reserved
• running

Damit koennen auch manuell/API-eingereihte Tasks nicht dazu fuehren, dass der Scanner zusaetzliche Arbeit ueber die reale Tageskapazitaet hinaus plant.

Wenn remaining <= 0, werden die Graphkandidaten weiterhin deterministisch sichtbar gemacht, aber nicht mehr vom Planner bewertet oder eingereiht. Die Entscheidungen tragen:

rejection_reason = daily_budget_exhausted
recommended_action = wait_for_next_utc_day_or_finish_queue

Das vom Benutzer bewusst auf 10 Minuten gesetzte

BRAIN_AUTONOMOUS_RESEARCH_INTERVAL=10m

wird dadurch nicht veraendert. Der Scanner darf weiterhin haeufig beobachten; er darf nur keine nicht konsumierbare Queue erzeugen.

Semantische Queue-Deduplizierung

Neben dem exakten DedupeKey gibt es jetzt eine deterministische semantische Deduplizierung ueber:

• normalisierte Topic-Terme;
• Seed-Node-Ueberlappung;
• Forschungsfragen.

Algorithmuskennung:

topic-seed-question-jaccard-v1

Eine gleiche ATT&CK-/Produkt-/Fehlercode-Wissensluecke bleibt dadurch dieselbe Queue-Arbeit, auch wenn sich die konkrete Seed-Menge zwischen zwei Scans leicht veraendert.

Vor dem Scan und beim Start des Autonomous-Workers werden alte queued/deferred Duplikate konsolidiert. Der hoechst priorisierte und bei Gleichstand aeltere Task bleibt Keeper; Inhalte werden zusammengefuehrt, redundante Tasks werden gecancelt.

Neue Telemetrie:

autonomous.research.task.merged
autonomous.research.queue.consolidated
semantic_queue_duplicate
daily_budget_exhausted

Running Tasks werden bei der Konsolidierung nie abgebrochen.

---

3. Article Type Reconsideration

Problem in v9

Viele Themen wurden als troubleshooting klassifiziert, obwohl die vorhandenen Quellen keinen belastbaren operationalen Ablauf mit mindestens drei konkreten Schritten trugen. Der Author konnte daraufhin trotz Zusatzrecherche solution_steps=0 liefern. Die harte Strukturpruefung verwarf den Entwurf noch vor der CPU-Quality-Stufe.

Das Quality-Gate war korrekt; der falsche Artikeltyp war das Problem.

v10: genau eine Reconsideration

Wenn ein operationaler Typ (troubleshooting oder how_to) nach der vorgesehenen Research-/Author-Runde an einem der folgenden harten Strukturfehler scheitert:

insufficient_solution_steps
missing_validation_steps

darf v10 genau einmal einen separaten Qwen-Replanner fragen, ob das vorhandene Evidence-Set fachlich besser als einer dieser Typen darstellbar ist:

reference
concept
decision_guide
skip

troubleshooting und how_to sind in diesem Replan absichtlich nicht mehr zulaessig.

Kein Quality-Bypass

Bei einer Reclassification wird der alte Entwurf nicht umetikettiert.

alter operationaler Draft
    ↓
Reconsideration
    ↓
neuer nicht-operationaler Typ
    ↓
Knowledge Brief fuer neuen Typ neu bauen
    ↓
Gemma schreibt komplett neu
    ↓
CPU Quality
    ↓
Qwen Claim Review + Coverage Review
    ↓
Final deterministic gates

Der neue Artikel muss damit die normalen v8/v9-Qualitaetsregeln vollstaendig bestehen.

Waehlt der Replanner skip, endet der Lauf sauber mit:

wrong_article_type_or_insufficient_operational_evidence

Planner-Prompt gehaertet

Der normale Artikelplaner erhaelt zusaetzlich folgende Regeln:

• troubleshooting nur wenn konkreter Fehler, Diagnose und Recovery zentral sind und die Quellen plausibel einen ausfuehrbaren Ablauf tragen;
• how_to nur wenn konkrete source-grounded Schritte plausibel vorhanden sind;
• allgemeine Hardening-, Prevention-, Framework-/Standard-Mapping-, Threat-Profile- oder Mechanismen-Themen sind nicht automatisch Troubleshooting;
• wenn die Quellen voraussichtlich keine drei konkreten Schritte tragen, ist ein nicht-operationaler Typ vorzuziehen.

Neue Pipeline-Identitaet

v10 verwendet:

adaptive_generate_review/v4-quality-routing-v10

und im Fingerprint zusaetzlich:

topic-guard=strict-v3-relation-evidence

Damit blockieren alte v9-Fehlversuche eine erneute Synthese unter dem korrigierten Routing nicht.

---

4. Vector Maintenance unabhaengig von Learning

Problem in v9

Periodische Vector-Reevaluation und Layoutpflege wurden innerhalb des Learning-Scan-Pfads angestossen. Bei Learning=false liefen deshalb auch die mathematischen Maintenance-Zyklen nicht mehr.

Ausserdem kann folgende Kombination missverstanden werden:

BRAIN_VECTOR_GRAPH_LAYOUT=true
BRAIN_VECTOR_GRAPH_RELAX_LAYOUT=true

LAYOUT=true bedeutet Vollayout und gewinnt gegen Relaxation. Eine sanfte Wolkenentspannung findet in diesem Zustand nicht statt.

v10-Maintenance-Loop

Nach Bootstrap laeuft eine eigene Maintenance-Schleife unabhaengig von Learning.

Sie prueft mindestens minuetlich, ob faellig sind:

• semantische Reevaluation via BRAIN_VECTOR_GRAPH_REEVALUATE_INTERVAL;
• sanfte Layout-Relaxation via BRAIN_VECTOR_GRAPH_LAYOUT_RELAX_INTERVAL.

Die eigentliche Berechnung bleibt dieselbe Vector-Mathematik und kann weiterhin auf vector_graph-Agenten ausgelagert werden.

Maintenance und Learning-Scan verwenden denselben Engine-Mutex, sodass sie Vector-Edges/Positionen nicht gleichzeitig ersetzen koennen.

Effektive Layoutmodi

v10 unterscheidet sichtbar:

off
relax
full

Regeln:

BRAIN_VECTOR_GRAPH_LAYOUT=true
    → full

BRAIN_VECTOR_GRAPH_LAYOUT=false
+ BRAIN_VECTOR_GRAPH_RELAX_LAYOUT=true
    → relax

beides false
    → off

Neue Status-/Eventfelder:

vector_graph_layout_mode
vector_graph_layout_relax_effective
layout_mode
layout_applied
periodic_refresh
layout_refresh

Wahrheitsgetreue last_vector_layout-Telemetrie

last_vector_layout wird nur bei tatsaechlichen Positionsupdates gesetzt. Um trotzdem zu verhindern, dass ein Neustart sofort eine sanfte Relaxation ausloest, fuehrt v10 einen separaten internen Process-Start-/Not-Before-Zeitpunkt. Die Telemetrie wird nicht mehr mit einem erfundenen Layoutzeitpunkt vorbelegt.

Empfohlene Dauerbetriebskonfiguration

BRAIN_VECTOR_GRAPH_LAYOUT=false
BRAIN_VECTOR_GRAPH_RELAX_LAYOUT=true
BRAIN_VECTOR_GRAPH_LAYOUT_RELAX_INTERVAL=2h
BRAIN_VECTOR_GRAPH_REEVALUATE_INTERVAL=30m
BRAIN_VECTOR_GRAPH_LAYOUT_BLEND=0.08
BRAIN_VECTOR_GRAPH_LAYOUT_MAX_SHIFT=0.035

Fuer beschleunigte visuelle Tests kann temporaer verwendet werden:

BRAIN_VECTOR_GRAPH_LAYOUT_RELAX_INTERVAL=10m

Wichtig: Fuer echte Relaxation muss BRAIN_VECTOR_GRAPH_LAYOUT=false bleiben.

---

5. Restart-stabile Autonomous-Research-Telemetrie

Die alten in-memory Summen zaehlten nur seit dem letzten Prozessstart. Dadurch konnten nach einem Restart im Status completed_total=0 oder articles_total=0 erscheinen, obwohl SQLite bereits abgeschlossene Tasks enthielt.

v10 liest die oeffentlichen Gesamtsummen aus dem persistenten Research-Task-Store:

completed_total
failed_total
evidence_total
articles_total

Die Prozesszaehler bleiben separat als:

process_totals

sichtbar.

Damit ist klar getrennt:

• persistente Historie;
• Aktivitaet dieses Prozesses.

---

6. Zusammenspiel der vier Fixes

Die vier Aenderungen greifen bewusst ineinander:

Graph Opportunity / Thinking Pair
        │
        ├─ Relation Research
        │    └─ nur einzeln akzeptierte Fulltext-Evidence darf Graphwissen werden
        │
        ├─ Autonomous Research
        │    └─ nur konsumierbare, semantisch deduplizierte Queue-Arbeit wird geplant
        │
        ├─ Article Synthesis
        │    └─ falscher operationaler Typ wird einmal korrigiert, nie weichgeprueft
        │
        └─ Vector Maintenance
             └─ mathematische Strukturpflege laeuft unabhaengig vom Learning-Schalter

Dadurch werden vier unterschiedliche Fehlerklassen getrennt behandelt:

• Evidenzqualitaet;
• Orchestrierungs-/Backlogqualitaet;
• Artikelsemantik/-granularitaet;
• mathematische Graphpflege.

Es gibt keinen gemeinsamen globalen „Quality“-Schalter, der diese Probleme verdeckt.

---

7. Relevante Events fuer den naechsten Realtest

Relation Research

think.research.query.rebuilt
think.research.insufficient

Erwartung:

• keine internen Node-IDs in oeffentlichen Queries;
• fachfremde Treffer werden vor Materialisierung verworfen;
• bei 0 akzeptierten Volltextbelegen keine beweisabhaengige Relation.

Autonomous Queue

autonomous.research.queue.consolidated
autonomous.research.task.merged
autonomous.research.scan.completed

Erwartung bei erreichtem Tagesbudget:

created = 0
rejection_reason = daily_budget_exhausted

und keine weiter wachsende redundante Queue.

Artikel

article.type.reconsidered
article.cpu_quality.completed
article.review.completed

Erwartung:

• ein operationaler Draft ohne belastbare Steps wird hoechstens einmal umgeplant;
• bei Reclassification entsteht ein neuer Draft;
• dieser erreicht CPU Quality und danach Claim-/Coverage-Review.

Vector Maintenance

vector.graph.maintenance.started
vector.graph.rebuilt
vector.graph.maintenance.completed

Erwartung bei LAYOUT=false + RELAX=true:

layout_mode = relax

und last_vector_layout aendert sich nur, wenn echte Positionsupdates geschrieben wurden.

---

8. Unveraenderte Grenzen

v10 aendert bewusst nicht:

• Vector Similarity-/Affinity-Schwellen;
• Orphan-Graph-Qualitaetsschwellen;
• solution_steps >= 3 fuer operationale Artikel;
• CPU-Quality-Mindesttiefe;
• Claim-/Coverage-Reviewer-Schwellen;
• Docker-Controller-Policy;
• Source-Inbox-Security-Gates;
• das vom Benutzer fuer Tests gesetzte BRAIN_AUTONOMOUS_RESEARCH_INTERVAL=10m.

Die Korrekturen betreffen Routing, Evidence-Materialisierung, Queue-Kapazitaet und Maintenance-Orchestrierung – nicht das Absenken bestehender Qualitaetsregeln.