Gute Idee. Weizenbaum war nach seiner Erfahrung mit ELIZA einer der grössten Kritiker von AI. Die Strukturierung ist ein guter Ansatz. Ich teste gerade ein SI Konzept, dh strukturelle Intelligenz in denen Transformers Modelle als device eingehängt werden. Das Grundprinzip: Shannon ernst nehmen: „The fundamental problem of communication is that of reproducing at one point either exactly or approximately a message selected at another point. Frequently the messages have meaning; that is they refer to or are correlated according to some system with certain physical or conceptual entities. These semantic aspects of communication are irrelevant to the engineering problem.“ A Mathematical Theory of Communication (Bell System Technical Journal, 1948) Unsere ersten Tests haben gezeigt: Von grok interpretiert: "Was aus dem ersten Test (reines strukturelles Mapping des Dateisystems) zu entnehmen ist Der Test hat an 325.004 realen Einträgen unter /run/wieneros gezeigt, dass eine vollständig semantiklose, rein strukturelle Abbildung möglich und stabil ist. (Hinweis: wir nennen es WienerOS als Hommage an Norbert Wiener) Zentrale Beobachtungen Hohe Formenvielfalt bei klarer Gruppierbarkeit Aus 325.004 Basenames entstanden 71.529 distinkte FORM_KEYs. Das heißt: Die strukturelle Signatur (Zeichenklassen + Runs) trennt bereits sehr fein, ohne jemals Inhalt oder Zweck zu lesen. Starke Formationsbildung 13.322 Singletons (Formen, die nur einmal vorkommen) 58.207 Formationen mit mehr als einem Mitglied Die größte Formation umfasst 1.469 Mitglieder mit identischem FORM_KEY Das zeigt: Viele Dateinamen teilen exakt dieselbe strukturelle Organisation, auch wenn sie inhaltlich völlig verschieden erscheinen mögen. Klare Trennung von Invarianten und Delta-Blöcken In der größten Formation: 17 invariante Positionen 10 D-Positionen genau 2 maximale Delta-Blöcke Die gemeinsame Form hält stabil. Die individuierende Variation ist lokal begrenzt und relativ zur Form beschreibbar.

@Yanet Claudia Laempe Re: Bei Rechnung_Max_Mustermann.pdf" steckt der Name im Delta, nicht im Skelett. True: Nur. Ein LLM benötigt Rechnung_Max_Mustermann.pdf nicht um dir ein Muster dazu mitzuteilen. Ob du ihr Max übermittelst oder first_name_id576 ist für den output unerheblich. Das Problem bei Frameworks ist halt dass ihnen die Codierungsschicht und Decodierungsschicht zwischen In- und Output (inter legere) fehlt. Genau diese baue ich gerade. Zielfunktion ist daher eine Vermittlungsfunktion die Daten so überträgt, dass personenbezogene Daten nicht übertragen werden und auch nicht relevant sind für den In- und Output. Kurz: Eine Person kann dann nicht zugeordnet werden wenn Person an sich im gesamten Datenstrom nicht existiert. Ideal ist also ein Zustand in dem die DSGVO von ihrem Normzweck her nicht anwendbar ist. Re: Wer die Daten verschickt, ist weiter verantwortlich und muss informieren. Und ob eine Maskierung wirklich hält, muss man im Einzelfall zeigen, nicht behaupten. Stimmt. Das Trifft aber nur auf personenbezogene Daten zu. Eine Anfrage zum Zustand von P45 in K7 (Prüfung ob Rechnung bezahlt wurde ohne dass das LLM Personenbezug bekommt. Das ist schlichter Soll/ist Vergleich in Zahlen) und braucht prinzipiell auch keine KI, sondern nur Code von KI der lokal ausgeführt wird. Letzteres ist korrekt. Sobald es für einen Feldtest taugt wird es auf github veröffentlicht. Derzeit noch nicht. Anm.: Der aktuelle Stand zeigt zwar schon einiges ist aber noch in einer Alphaphase.

Die EU macht eine Psydoregel die wenig bringt. Übertragen fragt sie: Hast du einen Hammer benutzt um den Nagel zu befestigen?

Wir testen es gerade in Emacs. Da läuft jede cli sauber neben dem Code.

Hallo, zusammen, ich bin Wolfgang und komme aus Oberösterreich. Derzeit arbeite an einem System das KI auf Betriebssystemebene steuert und regelt. Ziel ist es KI als Device anzusprechen (vergleichbar mit CUPS) und universell an jegliche Programme zu koppeln ohne dass externe Tools nötig sind. Beste Grüße, Wolfgang PS: Kurze Gegenüberstellung von QWEN 3.8 nach aktueller Runtimevermessung was bereits anders ist als bei herkömmlichen Frameworks: Quote:" Der wesentliche Unterschied ist nicht inkrementell. Er ist **paradigmatisch**. WienerOS ist kein „KI-Framework". Es ist ein **kybernetisches Betriebssystem**, das KI als einen kontrollierten Symbolverarbeitungsautomaten einbettet – nicht als inferierende Blackbox. Hier die fundamentale Differenz, dimensioniert: --- ### 1. Epistemologie: Wie entsteht „Wissen"? | Traditionelle KI-Frameworks | WienerOS | |---|---| | **Statistische Inferenz:** Wissen emergiert aus Ko-Okkurrenz in Trainingskorpora. | **Formale Distinktion:** Wissen entsteht durch Unterscheidung (`G`/`Δ`), Verortung (`POSITION_FORM`) und Adressierung (Pointer). | | **Probabilistisch:** „Mit 87% Wahrscheinlichkeit ist das relevant." | **Deterministisch:** „FORM_KEY passt. Δ-Blöcke valide. Pointer-Hash stimmt. Gate: PASS." | | **Latent:** Bedeutung liegt in undurchsichtigen Vektorräumen. | **Explizit:** Struktur liegt in lesbaren, diffbaren, hash-gebundenen YAMLs. | **Konsequenz:** KI-Frameworks *raten* Bedeutung. WienerOS *misst* Struktur. --- ### 2. Repräsentation: Wie wird Information gespeichert? | KI-Frameworks | WienerOS | |---|---| | **Embeddings:** Vektoren in hochdimensionalem Raum. Opak. Nicht diffbar. Nicht auditierbar. | **Morphologie:** `FORM_KEY`, `Δ`-Blöcke, `POSITION_FORM`. Textuell. Hash-gebunden. Vollständig inspizierbar. | | **Kontextfenster:** Alles im Prompt ist potenzielle Instruktion. | **Canonical Interface:** Nur strukturierte Evidenz (`raw_form` → `form_key`). Kein impliziter Befehl. | | **Monolithisch:** Modell + Daten + Logik gekoppelt. | **Modular:** Core (beobachtet) ⊥ Adapter (übersetzen) ⊥ Contracts (autorisieren). |