Module I — inventaire et découverte
Le module I est le catalogue du parc (estate) : un inventaire passif, piloté par le bus, de tout ce qui existe — agents, sessions, instances de Claude Code, serveurs MCP, skills, outils, ressources, modèles, fournisseurs et identités non humaines. Il découvre en écoutant, jamais en sondant, et n’enregistre que des relations, des identifiants et la vivacité — jamais de charges utiles. Cette page est la référence de ce que le catalogue contient et de ce qu’il ne contient délibérément pas.
Ce qu’il matérialise
Section intitulée « Ce qu’il matérialise »Les connecteurs émettent des observations, pas des entités. Ils publient sur le bus
d’événements des faits normalisés edge.observed et
cost.sampled ; les entités qu’ils impliquent ne sont jamais
envoyées. Le module I matérialise l’entité de cœur que chaque observation nomme à
partir de sa référence naturelle : une session/un agent/une identity d’origine, un
serveur MCP, un outil, une ressource, un skill, et — à partir des échantillons de coût —
un fournisseur et un modèle (découverts, sans tarification ; cela appartient à FinOps).
La matérialisation est idempotente sous une livraison « au moins une fois » :
find-or-create sur la clé naturelle, de sorte que la même observation vue deux fois ne
duplique jamais une entité.
Son contrat et ses entités
Section intitulée « Son contrat et ses entités »Le module enregistre une entité qui lui est propre, inventory.catalog_entry — une
surcouche de découverte attachée à chaque entité de cœur matérialisée. Elle enregistre
comment une chose a été trouvée, et non ce qu’elle a fait : une liste de sources de
signal, les hôtes sur lesquels elle a été vue, les horodatages de première et dernière
observation, un compteur d’occurrences, et un status de vivacité active ou stale. Un
balayage de péremption (staleness sweep) périodique marque une entrée comme stale
lorsqu’elle n’a pas été vue dans la fenêtre configurée, et la repasse à active dès qu’elle
réapparaît ; le balayage ne s’exécute que sur les tenants que le module a effectivement
observés (il ne peut pas, et ne le fait pas, énumérer les tenants). La surface de lecture
est restreinte et en lecture seule : un summary comptant par kind et par source, une liste
entities paginée filtrable par kind et par statut, et une vue de détail d’une entité unique.
Chaque lecture exige une permission de lecture à portée de tenant et placée sous espace de
noms (le palier viewer le plus bas suffit) ; l’ingestion est à haute fréquence et n’est pas
auditée par écriture. Les formes complètes vivent dans la
référence du bus d’événements et dans les interfaces typées du produit.
Ce qu’il consomme et produit
Section intitulée « Ce qu’il consomme et produit »Le module I est un pur consommateur. Il s’abonne à edge.observed, cost.sampled et
finding.reported et n’écrit que sa propre surcouche de catalogue et les entités de cœur
qu’il en dérive. Il n’émet aucun événement propre et n’expose aucune surface d’actionnement
— la découverte est, par nature, observe-et-catalogue. Les références qu’il persiste
arrivent déjà expurgées depuis les connecteurs ; le module les stocke verbatim et
n’ajoute aucun détail brut qui lui soit propre, de sorte que la propriété de donnée minimale
est une propriété du fil, maintenue de bout en bout.
- Catalogue des modules — où se situe le module I et la répartition honnête de l’actionnement (Actuate).
- Module III — la carte d’accès — le seul propriétaire du graphe R/RW et de la dérive.
- Référence du bus d’événements — les événements
edge.observed,cost.sampledetfinding.reportedqu’il consomme. - De zéro au graphe — peupler le catalogue et la carte sur le parc de démonstration.
- Vue d’ensemble de l’architecture — le moteur, les couches et le bus.