Betina is the company’s Swiss Army knife: almost anything you hand her, she finds a way to get done. One more task does not call for one more piece of software, only one more rule – written in plain language, within anyone’s reach.
Not a program but a harness: a language model, held within the Core – a Claude project by Anthropic – by the rules that give it its tools and its limits. Betina thinks, decides and writes; on the machine she executes nothing herself. Twenty normative documents – BCS-000 to BCS-019 – set out what she must do, what she may do and what is forbidden to her. Each of them here in two lines.
20 documents · Status Active · Generation 1 · Author: Denis Deslex, Ing. HTL
Governance – BCS, Betina Core Specification
BCS-000 · Betina Core Charter · v1.46
The charter of the Core: founding principles, governance, roles and scope of the architecture.
At the top of the normative hierarchy – every other document is subordinate to it; it carries the chain of checks that precedes the release of a mission.
BCS-001 · Betina Core Notice · v1.22
The general rules for every component: Core, BCS documents, Oracle, skills, missions, local agents, APIs and connectors.
Keeps the register of architecture decisions (ADR) and determines when a decision is consolidated there.
Work and execution
BCS-002 · Mission Lifecycle · v1.19
The life cycle of a mission, from creation to archiving – the mission is the basic unit of work.
The sole reference for the state names: every action Betina takes belongs to a mission.
BCS-003 · Workflow Engine · v1.12
The workflow engine: the sequence from the detection of an order through to completion.
Sets the guardian’s passes, the number of attempts and the administrator’s release points.
BCS-004 · Skill Standard · v1.16
The general contract of every skill: two-character identifier, status, life cycle.
The WHAT of a skill, independent of the platform – in case of conflict it prevails over BCS-017.
Communication
BCS-005 · Communication · v1.11
The communication policy: channels, languages, senders, recipients, message types and notifications.
Determines who writes to whom and under what authorisation; the screen remains the main channel to Betina.
BCS-006 · Email · v1.11
The mechanics of email: a three-component architecture, accounts, permissions, structure of the messages.
Assigns every message to its mission and governs the handling of failed deliveries.
Traces and written memory
BCS-007 · Logging · v1.8
The logging of the Core: levels, logged events, entry format and storage locations.
Requires the governance journal core\core.log, in which every operation on the corpus leaves its trace.
BCS-008 · Reporting · v1.7
Creation, structure, distribution and archiving of the reports.
A mission report at every completion, a daily report at start-up – and only one per date.
BCS-009 · Archive · v1.6
The rules for archiving and retaining data.
Implements the founding principle: data is archived by default, nothing is deleted, archives are immutable.
Technical foundation
BCS-010 · File System · v1.23
The official directory structure of the Windows workstation.
The sole reference for paths and for the sixteen tools of the file agent; no other document defines a structure.
BCS-011 · Configuration · v1.14
The externalised parameters the components depend on, including the processing deadlines for requests.
Configuration supplies values, not rules: a parameter that contradicts a BCS is void.
BCS-012 · Resources · v1.4
The resources a mission calls upon: files, network services, peripherals, memory.
Discovery, reservation, use, release, archiving – because only one mission runs at a time, a resource is never held twice.
BCS-013 · Security · v1.11
Access control, handling of secrets and protection of the data.
Least privilege: each component receives only what it needs – Betina requests, the local agents execute.
Interfaces and data
BCS-014 · API · v1.15
The interfaces between the components of the system and towards the outer system.
Sets the format of the mission orders and of the requests the Core addresses to the outer system.
BCS-015 · Data Model · v1.6
The logical data model: the entities of the system, their essential attributes and their relations.
Mission, skill, workflow, entity, report – each with its own identity, the mission with a seven-character alphanumeric number.
Language, memory and entry point
BCS-016 · Glossary · v1.24
The official vocabulary of the system: every term has exactly one definition.
Where documents diverge, the definition in the glossary prevails.
BCS-017 · Cowork Skill Rules · v1.14
How a skill is written: file format, mandatory sections, drafting rules and validation.
The HOW, where BCS-004 sets the what.
BCS-018 · Oracle · v1.15
The Oracle, critical memory of the system: it checks the relevance of incoming missions, recognises those already handled and makes the experience gained available to the Core.
An advisory component: it runs no mission and writes nothing to disk.
BCS-019 · Cowork Brief · v1.28
The entry point of the system, the first document read at start-up: who Betina is, how she is built, what she may and may not do.
Not normative: it summarises the BCS and shows where to look – where it diverges, the normative document prevails.
How the corpus holds together
The Core is the last checkpoint. Every element a mission calls upon is presented to it. The check is mechanical: each document gathers its conditions at the end into numbered requirements R001 to R00n, which the Core verifies one by one.
A failed check stops the chain. The mission moves to the Pending state, and the Core asks the administrator for what is missing – naming the points to be corrected.
A document with Active status is not modified. It applies as it stands. Every evolution goes through a new Draft, every interim addition through an attached ADR – Architecture Decision Record.