Modèle de données

Principe

Le modèle doit permettre de reconstruire ce qu’Orbit sait, pourquoi il le sait, quand il l’a appris et qui peut l’utiliser.

Le graphe est une projection de ce modèle, pas le modèle lui-même.

Entités Context OS

Brain

• id
• propriétaire / tenant
• capacité CU
• policies globales
• état de billing/context

Space

• id
• brain_id
• schema_type
• schema_version
• nom
• qualité
• confidentialité
• policy de retrieval

Memory

• id
• space_id
• catégorie/pilier sémantique
• parent éventuel
• contenu canonique
• état
• coût CU
• importance
• confiance
• fraîcheur
• timestamps
• permissions

MemoryRelation

Relations typées : parent, confirme, contredit, remplace, dérive-de, similaire-à, référence.

Source

Origine brute : provider, URI/id externe, checksum/version, date source, classification.

Provenance

Lien immuable entre Memory, Source, extracteur/workflow et transformations.

ConnectorBinding

Connexion autorisée vers une source, scopes, santé, curseur de sync et destinations autorisées.

ToolContextBinding

Déclare quels Spaces un tool peut lire/écrire pour un scope métier donné.

ToolObservation

Fait produit par un tool avant promotion éventuelle en Memory.

MemoryProposal

Candidat à l’écriture canonique, avec provenance, preuve, auteur et policy appliquée.

ContextPack

Snapshot du contexte livré : intention, fragments, scores, provenance, CU utilisés, policies et version moteur.

UsageEvent

Événement append-only pour tokens, compute, stockage, sync, tool, Brain/Space et attribution de coût.

Relation avec le modèle Studio existant

Les tables historiques Product, BrainEntry, StudioGeneration, CreativeLearning, etc. ne sont pas renommées mécaniquement.

• Product reste une unité de travail Studio pendant la migration.
• BrainEntry est une structure legacy à migrer vers Memory.
• les générations/QC/learnings restent tool-specific ;
• ToolContextBinding connecte Studio aux Spaces.

Avec 0 utilisateur actif, les mauvais noms peuvent être corrigés avant v1, mais sans réécrire inutilement le ledger, les jobs et les mécanismes déjà fiables.

Règles d’intégrité

• une suppression de Source ne doit pas effacer silencieusement la provenance ;
• une compression garde les liens vers les memories sources ;
• une Memory remplacée reste traçable ;
• les permissions sont vérifiées à la lecture et à la livraison ;
• un tool ne crée pas directement une Memory sans policy ;
• IDs externes ≠ clés primaires internes ;
• CU et crédits monétaires restent deux concepts séparés.