Knowledge est une infrastructure policy gouvernée pour agents IA de décision. C'est un petit ensemble de services qui répondent à une question avec un verdict déterministe, auditable, cryptographiquement signable :
Étant donné le contexte courant, est-ce que cette policy permet cette action ?
Le modèle mental en un paragraphe
Un agent (ou n'importe quel caller) envoie une action proposée et le contexte qu'il a. Knowledge détermine quelles règles s'appliquent, les évalue, et retourne un verdict : allowed, blocked, approval_required, observe. Les rules qui ont fired sont citées. L'état de la policy au moment de décision est gelé et signé. Un Policy Enforcement Point en aval vérifie l'enveloppe signée avant que l'action métier ne s'exécute.
AI investigates. Knowledge decides. The tool boundary enforces.
Ce que veut dire "Knowledge décide"
Non : Knowledge prend toute la décision business.
Oui : Knowledge fait la détermination policy - quelles règles s'appliquent, quel est le verdict déterministe, si une autorisation humaine est requise. L'agent décide de tout le reste (ce qu'il investigue, quelles preuves il rassemble, comment il communique). La frontière du tool est où la décision policy devient un résultat exécutable.
Vocabulaire
Policy - l'agrégat qui porte un ensemble de Rules liées plus un governance_log d'actes d'adoption / amendement / renouvellement. Chaque Policy a un owner et une chaîne d'approbateurs.
Rule - une directive active avec une sévérité (absolute_ban, hard_block, require_approval, informative, allow), un scope structuré, et optionnellement des rows de condition (triples {field, op, threshold}) qui doivent fire pour que la règle s'applique.
Target - une audience nommée qui reçoit des rules. Remplace le concept Namespace V2 retiré.
Consultation - le record d'audit d'un appel /check ou /resolve. Fige le contexte envoyé, les versions de rules citées, la règle dominante, le trace de précédence, le scope utilisé, le verdict et le normative hash.
Verdict - un parmi allowed, blocked, approval_required, observe, not_covered. Le résultat que le caller reçoit.
Signed verdict - l'enveloppe JWS qui wrappe une décision pour qu'un Policy Enforcement Point en aval puisse la vérifier. Optionnel par déploiement. Voir Enforcement.
Progressive context - le mécanisme par lequel un caller envoie ce qu'il a et Knowledge retourne les champs encore nécessaires pour atteindre un verdict. Voir Progressive context.
PEP (Policy Enforcement Point) - le wrapper côté client (décorateur Python, MCP proxy, code custom) qui vérifie l'enveloppe signée avant d'exécuter une action métier. Vit dans votre infrastructure, pas celle de Knowledge.
Où Knowledge s'insère dans votre stack
Knowledge n'est pas :
- Un remplacement de tout le paysage rules d'entreprise (Drools, IBM ODM, DMN, ServiceNow, moteurs custom). Gardez-les où ils font sens.
- Un moteur de workflow. Votre workflow orchestre le processus ; Knowledge gouverne des points de décision spécifiques à l'intérieur.
- Un vendor KYC. Il consomme le résultat KYC et applique la décision composite.
- Un RAG sur vos documents de policy. Il produit des verdicts déterministes avec rules citées, pas du texte retrouvé.
Knowledge est pour une classe spécifique de décisions :
- Décisions qu'un agent IA prend de façon autonome et qui nécessitent des résultats déterministes gouvernés par règles.
- Décisions qui doivent rester reproductibles pour l'audit de niveau régulateur des années plus tard.
- Décisions qui ont besoin de sémantique d'approbation explicite (
approval_requiredcomme verdict first-class). - Décisions dont l'exécution requiert une autorisation cryptographiquement vérifiable à la frontière du tool.
Services + ports
| Service | Port | Objectif |
|---|---|---|
knowledge-api | 8090 | Registry, engine, /check, /reason writer |
knowledge-ai | 8091 | Reasoning + rendering prose (utilise un LLM que vous configurez) |
asplenz-finops | 8092 | Breakdown des coûts LLM par tenant |
knowledge-ui | 3002 | Back-office registry |
mock-ui | 3004 | Workstation démo (par tenant) |
knowledge-email | 8093 | Handler inbound Postmark |
knowledge-slack | 8094 | Intégration Slack |
knowledge-mcp | n/a | Serveur MCP Python (stdio) |
knowledge-mcp-proxy | 8006 | Proxy de gouvernance devant un serveur MCP customer |
Endpoint health sur chaque service HTTP : /health.
Suite
- Quickstart : governed tool en Python - 5 minutes.
- Quickstart : MCP proxy en 5 minutes - 5 minutes.
- Enforcement - plus profond sur le modèle d'enveloppe signée.
- Progressive context - plus profond sur la boucle required_context.