Runtime neuro-symbolique

1. Résumé

OpenCradle passe d'« une plateforme on-premise qui exécute des agents » à une couche d'exécution contrôlée placée entre des agents probabilistes et les systèmes qu'ils peuvent affecter.

La boucle :

• les agents produisent des proposals — actions, plans et faits candidats ;
• le runtime évalue ces proposals au regard de contrats typés ;
• des règles symboliques (politiques, permissions, contraintes métier) déterminent ce qui peut s'exécuter ;
• les outils s'exécutent et produisent des observations ;
• des vérificateurs déterminent si la transition d'état visée a réellement eu lieu ;
• tout est consigné comme evidence, avec sa provenance.

Trois séparations portent l'ensemble de la conception :

Une proposal n'est pas une décision. La sortie d'un outil n'est pas une vérité vérifiée. Une exécution réussie n'est pas une vérification du résultat.

Cela ne rend pas un modèle de langage déterministe. Cela rend les conséquences de sa sortie gouvernées par des règles explicites et inspectables.

État actuel

Les phases 1 à 3 de la feuille de route (§19) sont implémentées, ainsi qu'un premier domain pack. Ce qui existe dans le code de Cradle :

Ce qui n'existe pas encore : l'ontologie d'exécution comme vocabulaire ou graphe (§9 et phase 4 intouchés) ; RDF, OWL ou SHACL nulle part (§8, phase 6) ; un format de manifeste de domain pack et sa distribution versionnée ; le rollback au sens de la restauration d'un instantané — seulement la compensation via un outil que le fournisseur propose.

Deux limites à énoncer clairement. Le registre de vérificateurs est livré vide : le moteur tourne, mais les vérificateurs concrets arrivent avec les domain packs, donc une action déclarant des post-conditions se termine aujourd'hui en inconclusive et est annulée. Et la passerelle ne lie que les appelants qui l'utilisent : la boucle d'outils de l'agent y passe, une synchronisation de fond non.

Le portail de risque préexistant gouverne les réponses adressées à des humains. Le runtime ajouté ici gouverne les actions sur des systèmes ; les deux ne sont pas encore unifiés.

2. Énoncé du problème

Les systèmes d'agents bâtis sur des modèles de langage partagent des modes de défaillance que l'ingénierie de prompts ne peut pas supprimer :

• Sortie probabiliste. La même entrée peut produire des actions différentes.
• Un prompt n'est pas une politique applicable. Une instruction dans un system prompt est une suggestion que le modèle peut suivre ; ce n'est pas une contrainte imposée par le système.
• Valide au sens du schéma ≠ valide au sens du métier. Un {"refund_amount": 480000} parfaitement typé peut rester une décision catastrophique.
• Effets de bord cachés. Un outil peut écrire plus que son nom ne le laisse entendre.
• État périmé. Le contexte sur lequel l'agent a raisonné peut ne plus décrire le monde au moment de l'exécution.
• Actions non autorisées. L'identité qui a raisonné n'est pas nécessairement celle qui a le droit d'agir.
• Reprises non idempotentes. Un « créer une facture » rejoué crée deux factures.
• Mauvaise lecture des résultats. 200 OK n'est pas « ce que je voulais s'est produit ».
• Preuves absentes. Une conclusion sans source traçable ne peut être ni auditée ni contestée.
• Pas de contrôle des post-conditions. La plupart des frameworks d'agents s'arrêtent à « l'outil n'a pas levé d'exception », ce qui n'est pas une affirmation sur le monde.

Les logs ne règlent pas cela. Un log dit ce qui a été appelé. Il ne dit pas si c'était autorisé, ni si l'effet visé tient.

3. Principes de conception

1. L'agent propose ; le runtime dispose. Génération et autorisation sont des sous-systèmes distincts.
2. Aucun effet de bord non contrôlé. Chaque effet passe par une passerelle qui connaît sa classe de risque.
3. Séparer le raisonnement de l'autorisation. Un modèle ne doit jamais être le composant qui décide qu'il en a le droit.
4. Valider avant l'exécution. Structure, identité, politique, pré-conditions.
5. Vérifier après l'exécution. De façon indépendante, sur le système cible.
6. Toute affirmation conséquente exige une preuve. Source, date, acteur.
7. Toute transition d'état doit être attribuable. À une décision, et par elle à une identité.
8. Les règles métier vivent hors des prompts. Dans du code, des politiques ou des modèles de contraintes — versionnés et testables.
9. L'approbation humaine est un objet de première classe, pas une issue de secours.
10. L'incertitude est représentée explicitement. confidence, unknown, needs_clarification sont des valeurs légitimes.
11. L'échec a plusieurs formes. Reject, repair, retry, compensate, escalate.
12. Déploiement local et sûreté sémantique sont deux sujets distincts. Tourner sur son propre matériel détermine où vivent les données. Cela ne dit rien sur la justesse ni l'autorisation d'une action.

4. Modèle de base du runtime

Architecture cible.

Agent · Task · Intent · Proposal · Plan · Action · Tool
Observation · Fact · Evidence
Policy · Permission · Constraint · Decision
Verification · StateTransition · HumanApproval · AuditEvent

Entités

Agent — unité de raisonnement adressable. Champs : id, role, skills, model_ref, permitted_scopes. Relations : produit des Proposals. Exemple : l'agent triage-support adossé à un modèle local 7B.

Task — unité de travail avec une origine. Champs : id, origin, input_ref, status, deadline. Exemple : un message Telegram entrant.

Intent — interprétation normalisée de ce qui est demandé. Champs : id, task_id, intent_type, slots, confidence. Exemple : refund_request{order_id: "A-119", amount: null}.

Proposal — action candidate d'un agent, explicitement probabiliste. Champs : id, task_id, agent_id, action, candidate_facts, evidence_refs, confidence, alternatives. Une Proposal ne s'exécute jamais d'elle-même.

Plan — ensemble ordonné de Proposals avec dépendances. Champs : id, steps, ordering_constraints, abort_policy.

Action — l'opération concrète demandée par une Proposal. Champs : action_type, target, arguments, side_effect_class, idempotency_key.

Tool — capacité enregistrée avec un contrat déclaré. Champs : id, version, input_schema, output_schema, side_effect_class, required_scopes, supports_dry_run.

Observation — sortie brute d'un outil ou d'un système externe. Champs : id, execution_id, tool_id, raw_ref, observed_at, reported_side_effects. Une Observation est une donnée, pas une vérité.

Fact — assertion normalisée acceptée par le système. Champs : id, subject, predicate, object, source_ref, asserted_at, confidence, verification_status. Un Fact est toujours attribuable.

Evidence — matériau qui soutient un Fact ou une Decision. Champs : id, kind (fragment de document, réponse d'API, capture, exécution de tests), content_ref, hash, collected_at, collector.

Policy — règle sur ce qui peut arriver. Champs : id, version, scope, rule_ref, effect, obligations. Exemple : « toute action irréversible en production exige un HumanApproval ».

Permission — octroi liant une identité à des actions sur des ressources. Champs : subject, action_type, resource_selector, conditions.

Constraint — invariant métier. Champs : id, domain_pack, expression, severity. Exemple : « un classement SH doit référencer au moins une source juridique en vigueur ».

Decision — verdict du runtime sur une Proposal. Champs : id, proposal_id, verdict, reasons, policy_results, required_actions, decided_at, decided_by, policy_version. La Decision est la seule chose qui autorise l'exécution.

Verification — contrôle qu'un état attendu tient, effectué indépendamment de l'outil qui l'a annoncé. Champs : id, execution_id, checks, status, evidence_refs.

StateTransition — changement validé sur une ressource. Champs : id, resource_ref, from_state, to_state, decision_id, verification_id, committed_at.

HumanApproval — acte d'autorisation par une personne. Voir §15.

AuditEvent — enregistrement append-only de tout ce qui compte. Champs : id, kind, subject_ref, actor, at, payload_hash, prev_hash.

Les distinctions qui comptent

5. Cycle de vie de l'exécution

Architecture cible.

Réception de l'entrée
  → Normalisation du contexte
  → Génération de la proposal
  → Validation du schéma de la proposal
  → Résolution de l'identité et des permissions
  → Évaluation des politiques
  → Contrôle des contraintes métier
  → Construction de la décision d'exécution
  → Demande d'approbation humaine si requise
  → Exécution de l'outil
  → Capture de l'observation
  → Normalisation des faits candidats
  → Contrôle de cohérence sémantique
  → Vérification des post-conditions
  → Validation de la transition d'état
  → Émission de l'audit event
  → Retour du résultat

Chaque étape peut clore l'exécution. Les issues possibles :

Deux règles encadrent ce tableau : les boucles de repair doivent être bornées (un budget de reprises fixe, au-delà duquel l'issue est escalate), et inconclusive n'est pas verified — cela ne doit jamais valider silencieusement.

6. Architecture à deux portails

Architecture cible.

Portail 1 — avant exécution

S'exécute une fois la proposal formée, avant que le moindre outil ne soit touché.

class ExecutionProposal(BaseModel):
    agent_id: str
    task_id: str
    action_type: str
    target: ResourceRef
    arguments: dict
    evidence_refs: list[str]
    confidence: float | None
    idempotency_key: str

Contrôles, par coût croissant :

1. Validation structurelle — schéma, champs requis, types, plages, énumérés.
2. Résolution d'identité — quel sujet agit, pour le compte de qui.
3. Autorisation — ce sujet détient-il une Permission pour cette action sur cette ressource.
4. Évaluation des politiques — règles de l'organisation et de l'environnement.
5. Pré-conditions métier — contraintes du domain pack actif.
6. Exigences de preuve — cette classe d'action exige-t-elle des preuves, sont-elles présentes et fraîches.
7. Exigences d'approbation — dérivées du niveau de risque et de la classe d'effet de bord.
8. Classification du risque — le système L1/L2 existant de Cradle, généralisé du « risque de réponse » au « risque d'action ».
9. Limites de coût et de débit — par tâche, par agent, par tenant, par fenêtre.
10. Environnement cible — la production est-elle seulement dans le périmètre de cette exécution.
11. Idempotence — cette idempotency_key a-t-elle déjà produit un effet.

La sortie est une RuntimeDecision, pas un booléen.

Portail 2 — après exécution

S'exécute après le retour de l'outil, avant la validation de la transition.

1. Schéma de sortie de l'outil — le résultat correspond-il au contrat déclaré.
2. Existence de la ressource attendue — ce qui devrait exister existe.
3. État attendu — la ressource est dans l'état demandé par l'action.
4. Invariants métier — le modèle métier reste cohérent.
5. Aucun effet de bord interdit — rien n'a changé hors du périmètre déclaré.
6. Fraîcheur de l'observation — la lecture de vérification est assez récente pour compter.
7. Complétude des preuves — l'affirmation est étayée.
8. Post-conditions — les conditions formelles attachées à l'action tiennent.
9. Disponibilité d'une compensation — si la vérification échoue, existe-t-il un chemin de retour.

Point critique : le vérificateur doit lire depuis une source indépendante partout où c'est possible — pas depuis l'appel qui a effectué l'écriture.

D'où l'ordre de préférence de l'architecture :

dry run → prepare / commit → transaction → écriture en attente → clé d'idempotence → action réversible → compensation → approbation avant commit.

« Un outil pur, sans effet de bord » est un idéal utile. Les intégrations réelles — prestataires de paiement, e-mail, déploiements, API tierces — ne peuvent souvent pas l'offrir. L'architecture doit l'assumer plutôt que l'écarter.

7. Couche symbolique

Architecture cible. La couche symbolique est délibérément plurielle. Ce n'est pas une technologie unique.

Schémas

Pydantic, JSON Schema, types TypeScript, Zod, modèles métier typés. Ils répondent à « est-ce bien formé ? », pas à « est-ce juste ? ».

Moteur de politiques

Autorisation, politiques de l'organisation, règles d'environnement, permissions d'action, contrôle du budget et du risque. Candidats : Open Policy Agent, Cedar, JSON Logic, ou un petit format déclaratif propre à Cradle. Aucun choix technologique ne doit précéder un audit de la stack actuelle — Cradle est en TypeScript/Node, ce qui rend un évaluateur embarqué plus attractif qu'un sidecar.

Ontologie et graphe de connaissances

RDF/RDFS, OWL, SHACL, property graphs, ou modélisation relationnelle ordinaire. Les distinctions :

• une ontologie définit classes, relations et contraintes ;
• un graphe de connaissances stocke des entités concrètes et leurs relations ;
• un raisonneur infère des conséquences et détecte des contradictions ;
• un moteur de validation vérifie la conformité des données à des formes.

Ce sont quatre métiers différents. Les confondre est la façon la plus courante de faire échouer un projet d'ontologie.

Validateurs métier

Le code ordinaire reste légitime et constitue souvent la bonne réponse : calculs de taxes, algorithmes de classement SH, règles de seuil, arithmétique des dates, consultations d'autorités externes, invariants transactionnels. N'essayez pas de tout exprimer en axiomes.

8. OWL, RDFS et SHACL — pragmatiquement

RDF représente la connaissance en triplets : subject → predicate → object.

RDFS définit un vocabulaire de base : classes, sous-classes, propriétés, domain, range.

OWL ajoute des axiomes logiques : classes disjointes, cardinalité, équivalence, propriétés inverses / transitives / symétriques / asymétriques / fonctionnelles.

SHACL valide des graphes de données concrets : propriétés requises, cardinalité, types, plages de valeurs, formes de graphe, messages personnalisés.

La limite qui façonne notre conception :

La logique métier opérationnelle est presque toujours en monde fermé : si l'autorisation n'est pas dans le système, l'action ne passe pas. OWL ne doit donc pas être présenté comme un moteur de règles métier universel. Pour la validation opérationnelle, préférez SHACL, un moteur de politiques, les contraintes de base de données et les validateurs applicatifs. Réservez OWL à ce pour quoi il est réellement bon : classification, subsomption, contrôle de cohérence sur un vocabulaire maîtrisé.

9. Ontologie d'exécution universelle

Architecture cible. Le vocabulaire propre à Cradle — indépendant du domaine, décrivant l'exécution de l'agent elle-même.

Agent          proposes        Proposal
Proposal       contains        Action
Action         targets         Resource
Action         invokes         Tool
Action         requires        Permission
Action         isGovernedBy    Policy
Policy         evaluates       Context
Tool           produces        Observation
Observation    supports        Fact
Fact           isSupportedBy   Evidence
Decision       evaluates       Proposal
Verification   checks          StateTransition
StateTransition changes        ResourceState
HumanApproval  authorizes      Decision
AuditEvent     records         RuntimeEvent

Contraintes sur ce vocabulaire :

• toute Action exécutée doit référencer une Decision de verdict allow ;
• les Actions à haut risque et irréversibles doivent référencer un HumanApproval ;
• toute StateTransition validée doit référencer une Verification ;
• tout Fact vérifié doit référencer une Evidence ou une source de confiance ;
• une Observation ne peut jamais être traitée comme un Fact vérifié ;
• les Proposals refusées ne doivent jamais atteindre l'exécution ;
• l'identité exécutante doit être celle autorisée par la Decision ;
• une exécution répétée avec la même idempotency_key ne doit pas dupliquer les effets.

Notez que ces contraintes sont vérifiables sans aucun RDF. Ce sont des règles d'intégrité sur des enregistrements du runtime. Une représentation en graphe est une implémentation possible, pas un prérequis.

10. Domain packs

Architecture cible. L'ontologie d'exécution est universelle. La connaissance métier se branche par-dessus.

domain-pack/
  manifest.yaml
  ontology/
  schemas/
  policies/
  validators/
  tools/
  verifiers/
  examples/
  tests/

id: customs.hs-router
name: Customs and HS Classification
version: 0.1.0
entities:
  - Product
  - HSCode
  - RegulatoryRule
  - Permit
  - Authority
  - LegalSource
policies:
  - source-priority
  - restricted-goods-routing
  - missing-attribute-escalation
verifiers:
  - hs-code-exists
  - legal-source-current
  - required-permit-resolution

Un pack est versionné, testable isolément, et chaque Decision enregistre la version du pack qui l'a produite.

Packs candidats : douane et commerce (produits, codes SH, règles de classement, autorisations, restrictions, autorités, sources juridiques), infrastructure et qualité logicielle (services, incidents, déploiements, commits, environnements, tests, approbations, règles de rollback), santé (patients, observations, actes cliniques, contre-indications, rôles, consentement, escalade).

11. Exemple détaillé — HS Router

1. L'OCR extrait la description d'une marchandise d'un document d'expédition.
2. Un LLM la normalise en attributs produit structurés.
3. Les attributs deviennent des faits candidats, chacun avec sa source.
4. Un générateur de candidats propose plusieurs codes SH.
5. Les règles de classement (code ordinaire) testent les attributs discriminants.
6. Si des attributs requis manquent, la Decision est needs_clarification — pas une supposition.
7. Les sources juridiques sont contrôlées par ordre de priorité et en vigueur.
8. Autorisations et restrictions sont résolues depuis le modèle réglementaire.
9. La Decision finale porte ses preuves et leur provenance.
10. Un LLM rédige l'explication lisible — et ne peut pas modifier la décision formelle.

{
  "proposal": {
    "product_type": "unmanned_aerial_vehicle",
    "candidate_hs_codes": ["8806.21", "8806.22"],
    "confidence": 0.78
  },
  "decision": {
    "status": "needs_clarification",
    "missing_facts": [
      "maximum_takeoff_weight",
      "maximum_range"
    ],
    "permitted_to_finalize": false
  }
}

Cinq étapes restent séparées : extraction, normalisation, classement, évaluation réglementaire, explication. Les fondre en un seul prompt est exactement la défaillance que cette architecture existe pour empêcher.

12. Exemple détaillé — UptimeHarbor

1. La supervision détecte une panne.
2. Un agent propose un diagnostic.
3. L'agent propose un changement de code ou d'infrastructure.
4. Le Portail 1 valide dépôt, environnement cible et permissions.
5. Le changement s'exécute dans un environnement isolé.
6. Tests et contrôles navigateur produisent des observations.
7. Un vérificateur contrôle si l'incident d'origine est résolu.
8. Le déploiement en production exige une décision de politique explicite et, si configuré, une approbation humaine.
9. La vérification post-déploiement contrôle la santé du service et le comportement côté utilisateur.
10. Une vérification en échec déclenche rollback ou escalade.

Les règles formelles qui distinguent cela d'un pipeline CI avec un LLM greffé :

• tests au vert ≠ incident résolu ;
• une vérification en staging n'autorise pas un déploiement en production ;
• la production ne doit pas tourner sur un commit non vérifié ;
• le résultat d'un déploiement doit être vérifié depuis une source indépendante ;
• un même incident ne doit pas engendrer des correctifs concurrents en double.

13. Modèle des effets de bord

Architecture cible. Chaque Tool déclare une side_effect_class, qui détermine les contrôles exigés.

Déclarer une classe erronée est un défaut sérieux : les garanties du runtime ne valent que l'honnêteté du registre d'outils. Les contrats d'outils doivent être relus comme des frontières de sécurité.

14. Confiance et provenance

Tout résultat conséquent porte :

source · actor · timestamp · model et version · tool et version · version de policy · version d'ontology / domain-pack · hash d'entrée · hash de sortie · evidence_refs · verification_status · confidence quand c'est pertinent

Le registre d'audit doit être append-only, ou autrement protégé contre la modification silencieuse — le chaînage par hash (prev_hash par événement) est le mécanisme crédible le moins coûteux et fonctionne sur le stockage SQLite existant.

Les champs de version ne sont pas de la bureaucratie. Quand une politique change, vous devez toujours pouvoir expliquer une décision prise au trimestre précédent selon les règles alors en vigueur.

15. Human-in-the-loop

L'humain n'est pas un recours pour quand la machine échoue. L'approbation est un objet du runtime avec son propre cycle de vie.

{
  "approval_id": "approval_123",
  "decision_id": "decision_456",
  "approver_id": "user_789",
  "scope": "production_deployment",
  "status": "approved",
  "expires_at": "2026-08-01T12:00:00Z"
}

Formes prises en charge : approve · reject · request changes · approve once · approve within scope · approve until expiration.

L'operator inbox existant de Cradle en est le germe. Le travail consiste à le généraliser de « approuver une réponse » à « approuver une Decision », et à rendre portée et expiration explicites.

16. Architecture de composants proposée

Architecture cible — composants logiques. Au début, ce sont des modules d'une même application, pas des microservices.

• Agent Gateway — point d'entrée des exécutions d'agents
• Context Resolver — assemble le contexte et l'horodate
• Proposal Service — crée et stocke les Proposals
• Schema Validator — validation structurelle
• Identity and Permission Resolver — qui agit, pour le compte de qui
• Policy Engine — évalue les politiques sur le contexte
• Domain Constraint Engine — enfichable : validateurs, SHACL, raisonneurs
• Ontology Registry — versions du vocabulaire
• Domain Pack Registry — découverte, chargement, versionnement
• Tool Gateway — le point de passage unique de tous les effets de bord
• Execution Sandbox — exécution isolée des actions risquées
• Observation Store — sorties brutes des outils
• Evidence Store — artefacts adressés par contenu
• Verification Engine — contrôles de post-conditions
• State Transition Manager — commit / abort
• Approval Service — approbations humaines
• Audit Ledger — journal d'événements append-only
• Repair Loop — cycles de correction bornés
• Runtime API and SDK — le contrat public

Le plus précieux de tous est le Tool Gateway. Sans point de passage unique pour les effets de bord, toutes les autres garanties ne sont qu'indicatives.

17. API suggérées

Illustrées en Python pour la lisibilité ; Cradle est en TypeScript, les contrats réels seraient donc des schémas Zod et leurs types inférés, selon les conventions du code existant.

class Proposal(BaseModel):
    id: str
    task_id: str
    agent_id: str
    action: ActionRequest
    facts: list[CandidateFact]
    evidence_refs: list[str]
    confidence: float | None

class RuntimeDecision(BaseModel):
    proposal_id: str
    verdict: Literal["allow", "deny", "repair", "clarify", "require_approval"]
    reasons: list[str]
    policy_results: list[PolicyResult]
    required_actions: list[str]

class ExecutionObservation(BaseModel):
    execution_id: str
    tool_id: str
    raw_result_ref: str
    observed_at: datetime
    side_effects: list[ObservedSideEffect]

class VerificationResult(BaseModel):
    execution_id: str
    status: Literal["verified", "failed", "inconclusive"]
    checks: list[VerificationCheck]
    evidence_refs: list[str]

18. Considérations de stockage

Aucun stockage unique ne convient. Répartir par usage :

Quatre points à énoncer clairement :

• une base vectorielle n'est pas une ontologie ;
• un graphe de connaissances ne remplace pas un stockage transactionnel ;
• un raisonneur OWL n'est pas un moteur d'autorisation ;
• le RAG n'est pas de la vérification.

19. Feuille de route

Phase 1 — contrats d'exécution typés. ✅ Implémentée. Proposal, Decision, Observation, Verification comme entités réellement persistées. Validation des schémas. Pré- et post-conditions explicites. Audit events.

Phase 2 — tool gateway piloté par les politiques. ✅ Implémentée. Invocation centralisée des outils, permissions, niveaux de risque, clés d'idempotence, règles d'approbation, support du dry-run.

Phase 3 — runtime de vérification. ✅ Implémentée, avec un registre de vérificateurs vide. Contrôles de post-conditions indépendants, capture des preuves, gestion des échecs, hooks de compensation. Le rollback se limite à la compensation.

Phase 4 — ontologie d'exécution. Non commencée. Vocabulaire de base, manifeste de domain pack, versionnement, projection des objets du runtime vers des entités de graphe. Un registre de domain packs existe dans le code, mais ni format de manifeste ni vocabulaire.

Phase 5 — premier domain pack. Partiellement implémentée, avant la phase 4. HS Router est le pilote : le pack évalue provisions et exemptions de l'UEEA en logique trivaluée face aux attributs produit connus, de sorte qu'un attribut manquant devienne une question explicite au lieu d'une décision silencieuse (§11). Il enveloppe le service HS Codes Router existant, dont les endpoints sont enregistrés comme outils read_only. Manquent encore : le vocabulaire d'entités lui-même, et l'empaquetage.

Phase 6 — raisonnement sémantique optionnel. Non commencée. RDF/RDFS, validation SHACL, OWL là où les contraintes s'y prêtent vraiment, requêtes de provenance sur graphe.

20. Risques et non-objectifs

Risques : coût de maintenance de l'ontologie · règles périmées · faux sentiment de sûreté · sur-formalisation · décalage entre raisonnement en monde ouvert et logique métier en monde fermé · impossibilité d'annuler des effets de bord externes · politiques contradictoires · latence ajoutée · preuves elles-mêmes peu fiables · dérive de versions entre packs, politiques et code · la difficulté intrinsèque de la modélisation métier.

Non-objectifs :

• rendre un modèle de langage déterministe ;
• encoder toute la connaissance en OWL ;
• remplacer le code applicatif par une ontologie ;
• approuver automatiquement toute action d'agent ;
• prouver qu'un système externe s'est comporté correctement quand aucune vérification indépendante n'est disponible ;
• considérer le déploiement local comme une sécurité suffisante.

21. Questions ouvertes

• Quelle est l'abstraction d'outils interne actuelle, et MCP peut-il servir de Tool Gateway unique ?
• Où doit s'exécuter l'évaluation des politiques — en processus ou en service séparé ?
• Quels objets du runtime existent déjà dans le schéma Drizzle, et lesquels exigent de nouvelles tables ?
• Comment les exécutions d'agents sont-elles persistées aujourd'hui, et cet enregistrement suffit-il à l'audit ?
• L'operator inbox existant est-il généralisable en Approval Service ?
• Comment versionner et distribuer les domain packs aux installations on-premise ?
• Quelles opérations exigent de vraies transactions plutôt qu'une compensation ?
• Quels faits exigent une vérification externe, et auprès de quelles autorités ?
• L'interopérabilité RDF est-elle importante pour le premier client, ou est-ce un goût purement architectural ?
• Le premier graphe doit-il être implémenté de façon relationnelle ?
• Quel pilote passe en premier — HS Router ou UptimeHarbor ?
• Quels system prompts actuels contiennent des règles métier qui devraient passer dans le code ou les politiques ?

22. Implémentation minimale initiale

Une tranche verticale, réalisable sans RDF, OWL ni base graphe :

Un appel d'outil piloté par les politiques, avec vérification des post-conditions.

1. Un agent propose une action.
2. L'entrée est validée contre un contrat typé.
3. Le moteur de politiques renvoie allow ou deny.
4. L'outil s'exécute via une passerelle centralisée.
5. Un vérificateur lit le système cible de façon indépendante.
6. Le runtime stocke Proposal, Decision, Observation, Verification et AuditEvent.
7. Une vérification en échec est retournée comme un échec, même si l'outil lui-même a signalé un succès.

Le point 7 résume toute la thèse. Tout le reste — domain packs, ontologies, raisonnement sémantique — n'est qu'une extension d'une boucle qui doit d'abord fonctionner dans sa forme la plus simple.

Agent Proposal
      ↓
Typed Contract
      ↓
Policy Decision
      ↓
Controlled Tool Gateway
      ↓
Observation
      ↓
Independent Verification
      ↓
Verified State Transition

23. Systèmes voisins

État actuel. Ce à quoi Cradle est comparé, et sur quoi porte réellement la comparaison. L'unité de comparaison est un mécanisme, pas un produit.

LangGraph n'est pas un concurrent

LangGraph est ce que l'acheteur exécute déjà. Cradle se place en dessous, entre le graphe et les outils. Son human-in-the-loop est réel : interrupt() interrompt l'exécution sur un appel d'outil, l'état du graphe survit via la couche de persistance, et une personne approuve, corrige les arguments ou rejette.

Ce que sa documentation ne décrit pas : des bornes à cette approbation, une expiration, une garantie d'usage unique, l'interdiction de l'auto-approbation, ou un journal résistant à la retouche.

En une ligne : LangGraph répond à « comment l'agent en est arrivé là ». Cradle répond à « pourquoi il en avait le droit ».

Le vrai voisin, c'est AWS Dogwood

Dogwood, ouvert sous Apache 2.0 en août 2026, étend Cedar aux séquences d'appels d'outils et est pris en charge dans Amazon Bedrock AgentCore Policy. Il fait ce que fait Cradle : une couche déterministe hors du modèle, où un appel proposé est accepté ou rejeté avant exécution.

AWS nomme lui-même ses limites, et elles tracent la frontière :

Conséquence : tourner sur son propre matériel n'est pas un confort secondaire. C'est la ligne de partage avec le voisin le plus proche.

Ce qui ne se compare pas

Une base vectorielle n'est pas une ontologie. Un graphe de connaissances ne remplace pas un stockage transactionnel. Un raisonneur OWL n'est pas un moteur d'autorisation. Le RAG n'est pas de la vérification.