KI-Harness (EN)

Betina ist das Schweizer Taschenmesser des Unternehmens: fast alles, was man ihr überträgt, findet sie einen Weg zu erledigen. Eine weitere Aufgabe verlangt nicht eine weitere Software, sondern nur eine weitere Regel – im Klartext geschrieben, für jeden machbar.

Kein Programm, sondern ein Harness: ein Sprachmodell, eingefasst im Core – einem Claude-Projekt von Anthropic – durch die Regeln, die ihm seine Werkzeuge und seine Grenzen geben. Betina denkt, entscheidet und schreibt; auf der Maschine führt sie selbst nichts aus. Zwanzig normative Dokumente – BCS-000 bis BCS-019 – legen fest, was sie tun muss, was sie tun darf und was ihr verboten ist. Jedes davon hier in zwei Zeilen.

20 Dokumente · Status Aktiv · Generation 1 · Autor: Denis Deslex, Ing. HTL

Governance – BCS, Betina Core Specification

BCS-000 · Betina Core Charter · v1.46
Die Charta des Core: Grundprinzipien, Governance, Rollen und Geltungsbereich der Architektur.
Spitze der normativen Hierarchie – alle anderen Dokumente sind ihr untergeordnet; sie trägt die Kontrollkette, die der Freigabe einer Mission vorausgeht.

BCS-001 · Betina Core Notice · v1.22
Die allgemeinen Regeln für alle Komponenten: Core, BCS-Dokumente, Oracle, Skills, Missionen, lokale Agenten, APIs und Konnektoren.
Führt das Register der Architekturentscheidungen (ADR) und bestimmt, wann eine Entscheidung dort konsolidiert wird.

Arbeit und Ausführung

BCS-002 · Mission Lifecycle · v1.19
Der Lebenszyklus einer Mission, von der Erstellung bis zur Archivierung – die Mission ist die Grundeinheit der Arbeit.
Einzige Referenz für die Zustandsnamen: jede Handlung von Betina gehört zu einer Mission.

BCS-003 · Workflow Engine · v1.12
Die Workflow-Maschine: die Abfolge von der Erkennung eines Auftrags bis zum Abschluss.
Legt die Durchgänge des Wächters, die Zahl der Versuche und die Freigabepunkte des Administrators fest.

BCS-004 · Skill Standard · v1.16
Der allgemeine Vertrag jedes Skills: Kennung aus zwei Zeichen, Status, Lebenszyklus.
Das WAS eines Skills, unabhängig von der Plattform – im Widerspruchsfall hat es Vorrang vor BCS-017.

Kommunikation

BCS-005 · Communication · v1.11
Die Kommunikationspolitik: Kanäle, Sprachen, Absender, Empfänger, Nachrichtenarten und Benachrichtigungen.
Bestimmt, wer wem schreibt und unter welcher Freigabe; der Bildschirm bleibt der Hauptkanal zu Betina.

BCS-006 · Email · v1.11
Die Technik der E-Mail: Architektur aus drei Komponenten, Konten, Berechtigungen, Aufbau der Nachrichten.
Ordnet jede Nachricht ihrer Mission zu und regelt die Behandlung fehlgeschlagener Sendungen.

Spuren und schriftliches Gedächtnis

BCS-007 · Logging · v1.8
Die Protokollierung des Core: Stufen, protokollierte Ereignisse, Format der Einträge und Ablageorte.
Verlangt das Governance-Journal core\core.log, in dem jede Operation am Korpus ihre Spur hinterlässt.

BCS-008 · Reporting · v1.7
Erstellung, Aufbau, Verteilung und Archivierung der Berichte.
Ein Missionsbericht bei jedem Abschluss, ein Tagesbericht beim Start – und nur einer pro Datum.

BCS-009 · Archive · v1.6
Die Regeln für Archivierung und Aufbewahrung der Daten.
Setzt das Grundprinzip um: Daten werden standardmässig archiviert, nichts wird gelöscht, Archive sind unveränderlich.

Technische Grundlage

BCS-010 · File System · v1.23
Die offizielle Verzeichnisstruktur des Windows-Arbeitsplatzes.
Einzige Referenz für Pfade und für die sechzehn Werkzeuge des Datei-Agenten; kein anderes Dokument definiert eine Struktur.

BCS-011 · Configuration · v1.14
Die ausgelagerten Parameter, von denen die Komponenten abhängen, einschliesslich der Bearbeitungsfristen der Anfragen.
Die Konfiguration liefert Werte, keine Regeln: ein Parameter, der einem BCS widerspricht, ist ungültig.

BCS-012 · Resources · v1.4
Die Ressourcen, die während einer Mission beansprucht werden: Dateien, Netzdienste, Peripheriegeräte, Speicher.
Entdeckung, Reservierung, Nutzung, Freigabe, Archivierung – weil nur eine Mission zur Zeit läuft, wird eine Ressource nie zweimal belegt.

BCS-013 · Security · v1.11
Zugriffskontrolle, Umgang mit Geheimnissen und Schutz der Daten.
Geringste Rechte: jede Komponente erhält nur, was sie braucht – Betina fordert an, die lokalen Agenten führen aus.

Schnittstellen und Daten

BCS-014 · API · v1.15
Die Schnittstellen zwischen den Komponenten des Systems und zum äusseren System.
Legt das Format der Missionsaufträge und der Anfragen fest, die der Core an das äussere System richtet.

BCS-015 · Data Model · v1.6
Das logische Datenmodell: Entitäten des Systems, wesentliche Attribute und Beziehungen.
Mission, Skill, Workflow, Entität, Bericht – jedes mit eigener Identität, die Mission mit einer siebenstelligen alphanumerischen Nummer.

Sprache, Gedächtnis und Einstieg

BCS-016 · Glossary · v1.24
Das offizielle Vokabular des Systems: jeder Begriff hat genau eine Definition.
Bei Abweichungen zwischen Dokumenten gilt die Definition des Glossars.

BCS-017 · Cowork Skill Rules · v1.14
Wie ein Skill geschrieben wird: Dateiformat, Pflichtabschnitte, Schreibregeln und Validierung.
Das WIE, wo BCS-004 das Was festlegt.

BCS-018 · Oracle · v1.15
Das Oracle, kritisches Gedächtnis des Systems: es prüft die Relevanz eingehender Missionen, erkennt schon behandelte und stellt die gewonnene Erfahrung dem Core bereit.
Beratende Komponente: es führt keine Mission aus und schreibt nicht auf die Festplatte.

BCS-019 · Cowork Brief · v1.28
Der Einstiegspunkt des Systems, das erste beim Start gelesene Dokument: wer Betina ist, wie sie aufgebaut ist, was sie darf und was nicht.
Nicht normativ: es fasst die BCS zusammen und zeigt, wo zu suchen ist – bei Abweichung gilt das normative Dokument.

Wie das Korpus zusammenhält

Der Core ist die letzte Prüfstelle. Jedes Element, das eine Mission beansprucht, wird ihm vorgelegt. Die Prüfung ist mechanisch: jedes Dokument fasst seine Bedingungen am Ende in nummerierten Anforderungen R001 bis R00n zusammen, die der Core eine nach der anderen prüft.

Eine fehlgeschlagene Prüfung hält die Kette an. Die Mission geht in den Zustand Pendant, und der Core verlangt vom Administrator die nötige Ergänzung – mit Angabe der zu korrigierenden Punkte.

Ein Dokument im Status Aktiv wird nicht geändert. Es gilt, wie es ist. Jede Weiterentwicklung läuft über einen neuen Draft, jede Zwischenergänzung über einen beigefügten ADR – Architecture Decision Record.