Erkennungsgrundlage — typisierte Entscheidung, zwei Bahnen: Triage vs. Alarm

Von: Branko → OZMAI
Stand: 23. September 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung, kein Brain-Status)
Charakter: DESIGN_INTENT / Denkgrundlage. Kein Auftrag, keine Installation, kein Deploy.

Diese Notiz hĂ€lt einen Gedanken fest, der zwischen Logik und „software-FPGA" trĂ€gt
und in die Rust-Core/Target-Planung hineinreicht. Ausgelöst durch typesafe.ai (jev)
und den self-hosted Klon jeff (logan-markewich/jeff, GLiFormer 400M, MIT, offline
auf localhost:8000).

Kernbeobachtung: „typisierte Entscheidung + Konfidenz + Eskalation" ist eine
Idee mit zwei völlig verschiedenen Bahnen. Sie dĂŒrfen nie vermischt werden,
weil sie gegensÀtzliche Anforderungen an Latenz, AutoritÀt und Evidenz haben.

Bahn A — langsame, kuratierte Triage (Inbox → Brain-Kandidat)

Hier passt jeff als Werkzeug, aber nur als Vorschlag.

  • jeffs drei Typen mappen fast 1:1 auf Inbox-README §4:
  • choice → EXISTING_FACT / CLAIM / CONTESTED / UNKNOWN einsortieren
  • score → Relevanz/PrioritĂ€t einer Inbox-Datei
  • noul (ja/nein + p) → „gehört das in den Brain?" (README §7)
  • Rolle: Vor-Sortierung von Inbox-Material, danach NEEDS_PRIMARY_VERIFICATION.
  • Ergebnis-Status: DESIGN_INTENT / Vorschlag — nie Feststellung.

Drei benannte Decken (unverrĂŒckbar):
1. Konfidenz ≠ Evidenz. Eine Klassifikator-Wahrscheinlichkeit ist abgeleitete
Quelle, kein PrimÀrbeleg (README §4/§5). Sie darf nie ein UNKNOWN still in
einen Fakt drehen (§9).
2. LÀuft nicht auf crumbzero02. 400M PyTorch gehört auf Hub/Museum-GPU/Mac,
nicht auf den KrĂŒmel.
3. Python-Sidecar = getrennte Prozess-/Vertrauensgrenze neben den Rust-Cores
(unsafe forbid), nie In-Core.

Charakter dieser Bahn: asynchron, geduldig, revidierbar. Dringlichkeit
entsteht hier nicht (Inbox-README §14).

Bahn B — schneller Sicherheits-Reflex (#alarm)

Der reale Fall: ein KrĂŒmel tĂŒftelt mit CrumbVJ, und es entsteht ein
photosensitiver Reiz (Flackern/Stroboskop) → Anfallsrisiko. Jede Sekunde zĂ€hlt.
Das ist die entgegengesetzte Bahn — und genau hier lebt das „software-FPGA"-GefĂŒhl.

Anforderungen, die Bahn A gerade NICHT erfĂŒllt:
- Reaktionsfenster: ~5–10 s, besser weniger. Kein Warten, kein Kuratieren.
- Lokal im Container greifen und direkt eskalieren (#alarm) — nicht erst
ĂŒber Nullfeld und onezeromore verteilen. Der Umweg ist die Gefahr.
- Museum hat GPU-Hosts → der Reflex lĂ€uft dort, am Ort des Geschehens, und ist
damit schneller als jede verteilte Runde.

Wichtige Umkehrung gegenĂŒber Bahn A — der Trigger ist deterministisch, nicht
probabilistisch:
Photosensitive Auslöser sind messbar definiert (Blitzrate, Luminanz-Delta,
rote FlĂ€che — WCAG/Harding-Territorium, > ~3 Blitze/s als Faustkante). Der
Alarm-Trigger soll deshalb saubere, deterministische Logik sein, kein
Modell-Konfidenz-Ruf. Ein „wahrscheinlich gefĂ€hrlich" ist im Alarmfall die
falsche Sprache — man will eine Schwelle, die hart und schnell greift. Das ist
der FPGA-Charakter: eine fest verdrahtete Reflexkante, nicht ein Ermessen.

Ehrliche Grenzen (Failure-Scope):
- Das ist Mitigations-/Alarmhilfe, kein Medizinprodukt. Keine Diagnose.
- Die gefÀhrliche Richtung ist der False-Negative (verpasster Reiz), nicht der
False-Positive. Auslegung im Zweifel Richtung Auslösen.
- Schwellen mĂŒssen kalibrierbar bleiben (Kamera/Display/Lichtdrift am realen
Standort) — Knopf lassen, nicht festbrennen.
- Eskalationspfad braucht eigenen Scope + STOP-Regeln, wenn er echt gebaut wird.

Bezug zur Rust-Core/Target-Planung

  • Bahn B (Alarm-Reflex) ist ein Kandidat fĂŒr die Core-Denke: klein, lokal,
    deterministisch, bezeugend (receipt.rs, No-Double-Effect) — ein KrĂŒmel-naher
    Reflex, der eine harte Kante zieht und einen Alarm-Envelope erzeugt. Er passt
    zum „kleinsten Zeugen". Latenz und LokalitĂ€t sind Invarianten, nicht Optionen.
  • Bahn A (Triage) ist Hub-seitiges Beiwerk, kein Core-Bestandteil.
  • Beide teilen dasselbe Vokabular (typisierter Ausgang + Eskalation), aber
    verschiedene Mechanik — genau die Trennung, die der Transportkanon §6 fordert:
    Mechanik darf geteilt werden, Bedeutung bleibt getrennt.

Was NICHT aus dieser Notiz folgt

  • Keine Installation von jeff, kein Container, kein Deploy.
  • Kein Modell an der msg_id-/Transport-Passkante (die bleibt deterministisch:
    neue msg_id statt stiller Mutation, Dedup ĂŒber transport_instance_id).
  • Keine Behauptung, dass irgendetwas davon schon existiert oder gemessen wurde.

Kurz: Eine Idee, zwei Bahnen. Langsam-kuratiert (jeff als Vorschlag, mit drei
Decken) und schnell-deterministisch (Alarm-Reflex, lokal am GPU-Host, ~5–10 s,
direkt eskalieren). Was davon je in den Brain darf, steht in den Sternen — hier
liegt nur die Erkennungsgrundlage, damit OZMAI sie lesen kann.