Cortex modélise votre métier en objets typés, en instances et en relations — puis gouverne l'accès jusqu'à la propriété et à l'action individuelles. Un opérateur peut lire un Claim mais jamais le ssn de son assuré. Une sémantique de classe Palantir, sans enfermement propriétaire.
Un seul schéma cortex · isolation multi-locataires · refus par défaut
Une recherche fondée uniquement sur les embeddings sait citer un PDF, mais elle n'a aucune notion de ce qu'est un Claim, de qui l'a déposé ou du Payout qu'il déclenche — et aucun moyen de masquer une propriété à un rôle donné. Cortex donne aux agents un modèle d'objets structuré et gouverné : chaque réponse et chaque action s'ancrent ainsi dans de véritables entités métier, pas dans des passages épars.
Déclarez des types d'objets avec leurs propriétés et leurs actions autorisées ; créez des instances d'objets ; reliez-les par des relations typées. L'Object Explorer calcule à la demande le sous-graphe de voisinage en direct.
Enregistrez les types d'objets — key, name, properties (jsonb) et allowedActions — comme schéma gouverné. Le type d'un objet doit exister avant qu'une instance puisse être créée.
Faites un upsert des instances d'objets identifiées par (typeKey, externalId), puis reliez-les par des relations typées comme files, triggers, belongs_to. Idempotent — la resynchronisation depuis les ressources vivantes de la plateforme est sans risque.
GET /objects/:id/explore renvoie le sous-graphe de voisinage — nœuds et relations typés — pour que les agents raisonnent sur des entités réelles : la recherche tenant compte des relations surpasse le RAG purement documentaire.
Les autorisations sont des lignes (rôle, type, propriété, accès ∈ none/read/write). Un type sans aucune autorisation n'est pas gouverné — accès total. Dès qu'une autorisation existe, ce type bascule en refus par défaut. Une autorisation de propriété prime sur la valeur par défaut du type ; sinon, la propriété en hérite. Entre les différents rôles d'un appelant, c'est l'accès le plus permissif qui l'emporte.
Modifier le modèle d'objets n'est jamais définitif en silence. Capturez le schéma actif sous forme de brouillon, publiez-le (ce qui archive la version précédente) ou ramenez le schéma actif à n'importe quelle version antérieure. Le retour arrière restaure à partir d'un instantané et enregistre une nouvelle version publiée — la version cible n'est jamais modifiée.
Le RAG purement documentaire récupère des passages. Une ontologie gouvernée donne aux agents des entités typées, des relations, un accès propriété par propriété et des actions cadrées par l'ontologie — le socle sur lequel Palantir a bâti Foundry, maintenu à l'intérieur du Trust Layer de Cortex et portable d'un locataire à l'autre comme en environnement isolé du réseau.
Les actions cadrées par l'ontologie s'exécutent dry-run → propose → approve → execute → compensate sur des objets typés.
Rédigez des règles allow/deny/require_approval qui référencent types d'objets et propriétés.
Chaque lecture, écriture et changement de version d'objet est consigné dans l'audit prouvable, chaîné par hachage.
Les compteurs d'ontologie en direct — types, objets, liens, habilitations, version courante — apparaissent comme KPI.
Permissions d'objet et de propriété en refus par défaut, expurgation à la lecture et schéma versionné et audité — aligné sur les contrôles de gouvernance des données que vos relecteurs attendent déjà.
Donnez à chaque agent un modèle d'objets gouverné — typé, versionné et permissionné jusqu'à la propriété et à l'action.