AI Harness

Betina est le couteau suisse de l’entreprise : à peu près tout ce qu’on lui confie, elle trouve le moyen de le faire. Un travail de plus ne demande pas un logiciel de plus, seulement une règle de plus — écrite en clair, à la portée de n’importe qui.

Ce n’est pas un programme, c’est un harnais : un modèle de langage encadré, dans le Core — un projet Claude d’Anthropic — par les règles qui lui donnent ses outils et ses limites. Betina raisonne, décide et rédige ; elle n’exécute rien elle-même sur la machine. Vingt documents normatifs — BCS-000 à BCS-019 — définissent ce qu’elle doit faire, ce qu’elle a le droit de faire et ce qui lui est interdit. Chacun se résume ici en deux lignes.

20 documents · statut Aktiv · génération 1 · auteur : Denis Deslex, Ing. HTL

Gouvernance — BCS, Betina Core Specification

BCS-000 · Betina Core Charter · v1.46
La charte du Core : principes fondateurs, gouvernance, rôles et périmètre de l’architecture.
Sommet de la hiérarchie normative — tous les autres documents lui sont subordonnés ; elle porte la chaîne de contrôle qui précède le feu vert d’une Mission.

BCS-001 · Betina Core Notice · v1.22
Les règles générales applicables à tous les composants : Core, documents BCS, Oracle, Skills, Missions, agents locaux, API et connecteurs.
Tient le registre des décisions d’architecture (ADR) et dit quand une décision s’y consolide.

Travail et exécution

BCS-002 · Mission Lifecycle · v1.19
Le cycle de vie d’une Mission, de sa création à son archivage — la Mission étant l’unité de travail fondamentale.
Référence unique des noms d’états : toute action exécutée par Betina appartient à une Mission.

BCS-003 · Workflow Engine · v1.12
Le moteur de workflow : l’enchaînement qui mène de la détection d’un ordre jusqu’à la clôture.
Fixe les passages du veilleur, le nombre de tentatives et les points de validation de l’administrateur.

BCS-004 · Skill Standard · v1.16
Le contrat général de tout Skill : identification par un code de deux caractères, statuts, cycle de vie.
Le quoi d’un Skill, quelle que soit sa plateforme — en cas de contradiction, il prévaut sur BCS-017.

Communication

BCS-005 · Communication · v1.11
La politique de communication : canaux, langues, expéditeurs, destinataires, types de messages et notifications.
Dit qui écrit à qui et sous quelle validation ; l’écran reste le canal principal avec Betina.

BCS-006 · Email · v1.11
La technique de l’e-mail : architecture à trois composants, comptes, permissions, structure des messages.
Rattache chaque message à sa Mission et règle le traitement des échecs d’envoi.

Traces et mémoire écrite

BCS-007 · Logging · v1.8
La journalisation du Core : niveaux, événements journalisés, format des entrées et emplacements.
Exige le journal de gouvernance core\core.log, où toute opération sur le corpus laisse sa trace.

BCS-008 · Reporting · v1.7
La création, la structure, la diffusion et l’archivage des rapports.
Un rapport de Mission à chaque clôture, un rapport de journée au démarrage — et un seul par date.

BCS-009 · Archive · v1.6
Les règles d’archivage et de conservation des données.
Concrétise le principe fondateur : les données sont archivées par défaut, rien n’est supprimé, les archives sont immuables.

Socle technique

BCS-010 · File System · v1.23
L’arborescence officielle du poste Windows.
Référence unique des chemins et des seize outils de l’agent fichiers ; aucun autre document ne définit d’arborescence.

BCS-011 · Configuration · v1.14
Les paramètres externalisés dont dépendent les composants, délais de service des demandes compris.
La configuration fournit des valeurs, pas des règles : un paramètre qui contredirait un BCS est invalide.

BCS-012 · Resources · v1.4
Les ressources mobilisées pendant une Mission : fichiers, services réseau, périphériques, stockage.
Découverte, réservation, utilisation, libération, archivage — l’exécution d’une seule Mission à la fois garantit qu’une ressource n’est jamais prise deux fois.

BCS-013 · Security · v1.11
Le contrôle d’accès, la gestion des secrets et la protection des données.
Moindre privilège : chaque composant n’accède qu’à ce dont il a besoin — Betina demande, les agents locaux exécutent.

Interfaces et données

BCS-014 · API · v1.15
Les interfaces entre les composants du système et avec le système extérieur.
Fixe le format des ordres de Mission et des demandes que le Core adresse au système extérieur.

BCS-015 · Data Model · v1.6
Le modèle de données logique : entités du système, attributs clés et relations.
Mission, Skill, Workflow, entité, rapport — chacun avec son identité, la Mission portant un numéro de sept caractères alphanumériques.

Langue, mémoire et entrée en matière

BCS-016 · Glossary · v1.24
Le vocabulaire officiel du système : chaque terme y a une définition unique.
En cas de divergence entre documents, c’est la définition du glossaire qui fait foi.

BCS-017 · Cowork Skill Rules · v1.14
Comment un Skill se rédige : format du fichier, sections obligatoires, règles d’écriture et validation.
Le comment, là où BCS-004 fixe le quoi.

BCS-018 · Oracle · v1.15
L’Oracle, mémoire critique du système : il contrôle la pertinence des Missions entrantes, repère celles déjà traitées et met l’expérience acquise à disposition du Core.
Composant consultatif : il n’exécute aucune Mission et n’écrit pas sur le disque.

BCS-019 · Cowork Brief · v1.28
Le point d’entrée du système, premier document lu au démarrage : qui est Betina, comment elle est architecturée, ce qu’elle peut et ne peut pas faire.
Non normatif : il résume les BCS et indique où chercher — en cas de divergence, le document normatif fait foi.

Comment le corpus tient

Le Core est le validateur final. Tout élément mobilisé par une Mission lui est soumis. Le contrôle est mécanique : chaque document résume en fin de texte ses conditions en exigences numérotées R001 à R00n, que le Core vérifie une à une.

Un contrôle qui échoue arrête la chaîne. La Mission passe à l’état Pendant et le Core demande à l’administrateur le complément nécessaire, en précisant les points à corriger.

Un document Aktiv ne se modifie pas. Il fait foi en l’état. Toute évolution passe par un Draft nouveau, tout complément intermédiaire par un ADR joint — Architecture Decision Record.