Omni Capability API

Idée

Une capacité (traduire, résumer, transcrit, analyser une image) doit exister indépendamment du fournisseur qui l'exécute.

Problème

Chaque fournisseur expose ses propres modèles et formats : le code client est couplé à un fournisseur, et aucune garantie n'existe sur la capacité réellement exécutée.

Pourquoi une solution classique ne suffisait pas

Les routers classiques basculent par fournisseur, pas par capacité. Rien ne vérifie qu'un fournisseur sait réellement faire ce qui lui est demandé, ni ne garantit un comportement identique après bascule.

Mécanisme original

Preuves de capacité : chaque fournisseur est enregistré pour les capacités qu'il peut réellement réaliser ; l'exécution passe par des jobs idempotents avec état « unknown » explicite et réconciliation.

Difficultés

• Garantir l'idempotence des jobs malgré les erreurs réseau
• Représenter l'état « unknown » (résultat inconnu) sans mensonge
• Contrat fail-closed : en cas de doute, ne pas prétendre au succès

Choix techniques

Résultat actuel

Une couche d'abstraction où la capacité est indépendante du fournisseur, avec preuves de capacité et contrat fail-closed.

Ce que ce projet nous a appris

Une couche d'abstraction où la capacité est indépendante du fournisseur, avec preuves de capacité et contrat fail-closed.

Client -> capability registry -> adapters -> fournisseurs (jobs, artifact store, état unknown, reconcile)