Enterprise Application Intelligence · Plateforme d'agents de construction d'applications d'entreprise
Le cosmos accueille tous les instruments ; chaque instrument est façonné avec mesure
Une intelligence tangible, des applications fiables : ce que l'IA construit est visible, et chaque système livré supporte la mesure et la vérification.
Vous décrivez les besoins métier ; la plateforme AliothStudio construit le système. Hangzhou Yuqi Technology contraint ses agents avec le modèle d'ontologie de données Alioth développé en propre et gèle une fois pour toutes la structure de la base de données via la chaîne de publication du modèle (les agents n'écrivent jamais de DDL) et produit de façon déterministe, sur ce modèle gelé, les API backend, les définitions de types et l'interface utilisateur — livrant non pas une démo qui « a l'air de fonctionner », mais des applications d'entreprise vérifiées par 229 portes qualité et prêtes pour la production.
Le modèle est open source sur GitHub : github.com/CosmicTools9/Alioth · Dernière version v10.0.44 (2026-10-19)
Solutions
Ce que nous résolvons pour vous
Trois dilemmes typiques de la construction d'applications d'entreprise — et la réponse de Yuqi à chacun.
Les agents généralistes produisent des systèmes « d'apparence complète mais inexécutables »
Les LLM inventent des tables, champs, API et règles métier inexistants ; le résultat a l'air complet mais ne fonctionne pas — et les exigences strictes d'exactitude des applications d'entreprise confinent la plupart des outils de génération par IA au stade de la démonstration.
Notre réponse : contraindre l'agent par un modèle ontologique gelé — tout artefact structurel doit être localisé par héritage dans les 645 coordonnées sémantiques ontologiques et s'aligner champ par champ sur des contrats lisibles par machine ; les hallucinations sont détectées et rejetées dès la compilation.
Les systèmes assemblés à coups de formulaires ne suivent pas le métier
Les plateformes low-code traditionnelles assemblent des formulaires : les structures se dupliquent par des chemins latéraux et les sémantiques se dispersent ; dès que le métier change, le système sombre dans un marécage où chaque réparation en casse trois autres.
Notre réponse : piloté par l'ontologie — le monde métier est d'abord décrit avec précision dans un langage ontologique mathématisé ; un changement métier est un changement de modèle, et le système évolue avec le métier, sans correctifs sur du code vieillissant.
Un système métier se construit en des mois, et les besoins n'attendent pas
La conception de la base de données, les API backend et l'interface utilisateur avancent séparément, l'intégration et les reprises s'accumulent couche par couche — au moment de la livraison, les besoins du métier ont souvent déjà bougé.
Notre réponse : la structure de données est gelée une fois par la chaîne de publication du modèle, physiquement séparée de la chaîne de construction ; le pipeline d'agents ne produit que les API backend, les définitions de types et l'interface utilisateur — la couche applicative est générée d'un seul tenant, sans aucun DDL ni correctif de modèle.
Proven in Production
Déjà en fonctionnement dans ces secteurs
Le même modèle Alioth et la même plateforme AliothStudio tournent déjà comme systèmes de production, déployé dans 6 espaces de noms — 15 applications, 61 modules, 293 Blocks, 82 services (le sixième espace MAT est en cours d'intégration) couvrant toute la chaîne, de la demande au règlement et de l'affrètement à la facturation.
Système intégré de gestion des commandes et des finances pour la confection de commerce extérieur
Couvre 18 scénarios métier — vue d'ensemble des opérations, demandes clients, devis, commandes, nomenclatures (BOM), achats, échantillonnage, production, contrôle qualité, expéditions, documents, comptes clients/fournisseurs, ancienneté des créances, taux de change, coûts, marges, remboursement de taxes à l'export, notes de frais, permissions et paramètres — reliant toute la chaîne « demande → expédition → règlement ».
Système de gestion des opérations logistiques et de transport
Quatre modules — logistique sous-traitée, exécution du transport, comptes de produits et comptes de charges — avec une chaîne de collaboration externe « client ↔ plateforme ↔ transporteur » et un mécanisme de traçabilité des arbitrages intégrés ; gestion unifiée des lettres de voiture, trajectoires, géoclôtures, règlements et facturation.
Plateforme de gestion de la R&D système et de la navigabilité
Pour les clients de l'industrie aéronautique : gestion de la R&D système, workflows d'approbation et modules de conformité de navigabilité, avec modélisation ontologique des ingénieurs, étiquettes de compétences, rôles d'approbation et comités de contrôle des changements (CCB).
Données de référence et gestion budgétaire des projets de R&D
Registres de projets de R&D, attribution et réattribution tracées des numéros de dossiers de recherche, étiquetage multidimensionnel des projets, archives de lancement versionnées, relations de dépendance entre projets et de report des crédits, liaison des plans du domaine budgétaire — zéro table redondante, tout est ancré à la structure du modèle unifié.
How It Works
Comment la plateforme travaille pour vous
Vous n'avez qu'à formuler les besoins métier ; l'agent de construction d'applications d'entreprise d'AliothStudio fait le reste. La plateforme se compose de deux chaînes indépendantes : la chaîne de publication du modèle produit le socle de données, et la chaîne de construction d'applications assemble votre application métier sur le socle gelé.
Le socle de données lui-même est maintenu par une chaîne de publication du modèle indépendante (le canal unique de la structure), et l'agent n'utilise aucun DDL tout au long de la chaîne de construction — le système que vous recevez reste toujours ancré au même modèle gelé :
Plateforme de métadonnées
Le pivot de la gestion du cycle de vie du modèle. Tout changement structurel n'entre dans le pipeline de publication qu'après validation manuelle ; le moteur de génération intégré compile automatiquement les besoins métier en configuration d'application et en code.
Entrée unifiée
Le runtime unifié des applications métier : il découvre les applications automatiquement et charge les extensions (contraintes / règles / machines à états / workflows), avec une autorisation unifiée. Chaque système sectoriel est compilé et déployé indépendamment, sans interférence.
Authentification unique
Un service d'authentification unifié déployé indépendamment ; toutes les applications partagent la même chaîne d'identité — une seule connexion, un accès partout.
Portail de collaboration
Un cadre de portail pour les collaborateurs externes (clients, fournisseurs), activable à la demande et déployé indépendamment, partageant la même base de données que les systèmes internes.
Reliability
Pourquoi c'est fiable : libérer les agents des hallucinations du LLM
Le plus grand risque d'ingénierie du développement par agents généralistes est l'hallucination du LLM — le modèle invente des tables, champs, API et règles métier inexistants, produisant des artefacts d'apparence complète mais inexécutables. La réponse de Yuqi est de contraindre l'agent par le modèle ontologique : le LLM ne fait que la compréhension des besoins et le mapping ontologique ; tout artefact structurel doit être localisé par héritage dans l'espace ontologique gelé et ancré à des contrats lisibles par machine. Sous la double pression de la structure mathématique et des portes d'ingénierie, l'hallucination n'a nulle part où se loger — satisfaisant ainsi les exigences strictes d'exactitude et de fiabilité des applications d'entreprise.
Hériter pour se localiser — jamais inventer
Les actions structurelles de l'agent sont confinées à l'espace ontologique du schéma isahl gelé : l'extension ne peut qu'hériter dans le cône inférieur de l'ordre DAG et lier des coordonnées ontologiques tridimensionnelles, attribuées par un mécanisme de déclencheurs et non inventées par le modèle — le LLM ne peut pas inventer de tables ni de champs inexistants, et les nouvelles industries s'intègrent avec zéro DDL et zéro correctif de modèle.
Les artefacts s'alignent sur les contrats du paquet de publication
Les paquets Alioth/v* embarquent des contrats lisibles par machine et des rapports de vérification ; chaque artefact de l'agent — module, Block, Service, app.json — doit s'aligner champ par champ sur le contrat. Toute référence hallucinée (un service pendant, une coordonnée inexistante) est détectée et rejetée dès la compilation.
229 portes vérifiées mécaniquement
Le chemin complet de l'exigence au déploiement est gardé par 229 portes enregistrées sur toute la chaîne (137 en phase commit / 92 en phase push) : la légalité des coordonnées sémantiques ontologiques, l'intégrité des références structurelles et le succès de la compilation et des tests sont tous jugés par la machine — sans dépendre de l'attention de réviseurs humains ni de la confiance du modèle. Les artefacts hallucinés ne peuvent franchir les portes vers la production.
Le LLM ne génère pas le code d'exécution
La logique métier d'exécution est produite de façon déterministe par le générateur alioth-gen à partir de la configuration ontologique (API, types, interface — sans DDL : les changements de structure passent uniquement par la chaîne de publication du modèle) ; les invariants du noyau théorique sont en outre prouvés mécaniquement en Lean 4 (zéro sorry comme critère strict de la porte de push). Le LLM ne fait que ce qu'il sait faire — compréhension des besoins et choix de mapping — tandis que l'exactitude est garantie par la structure et la preuve.
Get Started
Comment démarrer
Quatre voies d'entrée, de la pratique à la profondeur : essayez en ligne, suivez le manuel, lisez la théorie ou auditez le code — chaque promesse peut être vérifiée par vous-même.
Édition SaaS d'apprentissage
cosmic-tools.shop propose une édition SaaS en ligne d'AliothStudio pour l'apprentissage — un déploiement allégé destiné aux particuliers, avec la modélisation centrale, l'assemblage d'applications et les flux d'exécution pleinement utilisables ; aucun environnement local n'est requis pour suivre le Livre bleu pas à pas.
Livre bleu de construction
« Manuel de construction d'applications AliothStudio » : le parcours opérationnel complet, de la préparation de l'environnement, du centre de modèles, des workflows AppAgent et des règles d'or du développement de modules et Services, jusqu'à la compilation, le déploiement et l'aide-mémoire des 229 portes qualité.
Livre blanc théorique
« Livre blanc de la théorie du modèle Alioth » : les fondements mathématiques de l'ontologie de l'échange — catégories de l'échange et symétrie de groupoïde, espace produit de coordonnées, complétude des cinq domaines, mesures de conservation, validation par théorie des modèles sur plusieurs espaces de noms, et preuves mécaniques Lean de cinq métathéorèmes centraux.
Vérification open source sur GitHub
Le modèle central est open source sur CosmicTools9/Alioth (PLpgSQL · MIT) : la dernière version v10.0.44 (2026-10-19) contient 1022 tables héritées + 268 tables graines, chaque publication étant vérifiée par reconstruction complète dans une base de validation dédiée — chaque propriété mathématique affirmée dans le livre blanc possède dans le dépôt sa définition structurelle et sa contrainte correspondantes.
Le générateur d'applications CosmicTools9/dsh-alioth (TypeScript) : l'utilisateur décrit l'application en dialogue, et le cadre produit par un pipeline programmatique déterministe des artefacts importables dans AliothStudio — le LLM ne fournit que des paramètres structurés et des décisions sémantiques, jamais le texte des artefacts. C'est l'implémentation vérifiable de la promesse « sans hallucination de LLM ».
Technology
Capacités techniques
| Capacité | Description |
|---|---|
| Autorisation fine NGAC | Modèle d'autorisation fondé sur un DAG implémentant la norme internationale NGAC (ANSI/INCITS 565-2022) : isolation multi-locataire par classes de politiques, héritage hiérarchique des attributs utilisateur/objet, autorisations par association et règles d'interdiction (l'autorisation négative prime), audit complet des changements de politique. |
| Routage intelligent des requêtes SQL / AGE | Le backend s'adapte automatiquement entre requêtes relationnelles et requêtes de graphe : les vérifications de permissions à haute fréquence passent par SQL (1–2 ms) ; les parcours multi-sauts et les plus courts chemins passent par le moteur de graphes Apache AGE. Les tables relationnelles restent l'unique source de vérité ; AGE est une couche d'accélération optionnelle. |
| Génération d'applications par IA | Le runtime AppAgent pilote par machine à états la chaîne automatisée « besoin → prototype → mapping ontologique → artefacts module / Block / Service » ; le pipeline d'injection de connaissances EmpAgent garantit la complétude symétrique des connaissances du domaine. |
| Vérification formelle Lean 4 | Les invariants du noyau théorique (conservation de la valeur, structuralité de l'involution, terminaison et correction de la complétion, décidabilité de la complétude des cinq domaines) sont prouvés mécaniquement en Lean 4, zéro sorry étant un critère strict de la porte de push — la justesse mathématique est vérifiée par le prouveur, non endossée par une revue. |
| Identité distribuée et audit | Les données métier utilisent des identifiants uniques distribués (zuid) ; toutes les opérations tombent dans un schéma d'audit indépendant, permettant, avec le modèle de symétrie transactionnelle, une traçabilité de bout en bout. |
| Chaîne de publication intégrée | Artefacts générés par Meta → compilation de l'espace de noms → paquet de déploiement (binaire + DDL + docker-compose + scripts d'exploitation) ; la passerelle redémarre automatiquement en phase de production, et le processus de publication est en boucle fermée et réversible. |
| Stack technologique moderne | Backend en Rust (haute performance, sûreté mémoire) ; frontend en React + TypeScript ; base de données PostgreSQL + extension graphe Apache AGE ; ingénierie fondée sur un monolithe modulaire pnpm / Cargo workspace. |
Theory
Fondement théorique : le modèle d'ontologie de données Alioth
Pourquoi ce modèle peut-il contraindre l'agent ? Parce qu'Alioth est un cadre de modélisation ontologique de données de niveau entreprise bâti sur la théorie des catégories et le principe de symétrie : le comportement économique est formalisé comme des morphismes dans une catégorie de l'échange, les transactions réversibles forment le groupoïde cœur (core groupoid), et la symétrie est strictement caractérisée par un endofoncteur involutif — chaque transaction possède une unique transaction inverse en miroir, garantissant la conservation de la valeur et l'intégrité structurelle. Tous les invariants mathématiques sont ancrés à des portes d'ingénierie, et les théorèmes centraux sont prouvés mécaniquement en Lean 4. Le modèle est open source : github.com/CosmicTools9/Alioth.
Catégorie / groupoïde / endofoncteur involutif
Les transactions sont des morphismes dans une catégorie de l'échange 𝓔 ; les transactions réversibles forment le groupoïde cœur core(𝓔) ; la symétrie = un endofoncteur involutif S : core(𝓔) → core(𝓔)ᵒᵖ avec S² = id. Conséquence d'ingénierie — la transaction miroir existe de façon unique et la conservation de la valeur est attestée écriture par écriture : chaque pièce comptable enregistre les soldes d'ouverture et de clôture, de sorte que « état antérieur + variation nette = état postérieur » est vérifiable mécaniquement ligne par ligne.
Catégorie produit / foncteur de coordonnées
Le foncteur de coordonnées χ = (dk_scene, dk_factor, dk_function) situe chaque entité métier en un point unique de la catégorie produit S × F × U : les trois dimensions sont orthogonales, prennent leurs valeurs indépendamment et évoluent indépendamment ; les codes dimensionnels sont des adresses hiérarchiques attribuées par un mécanisme de déclencheurs, non par convention humaine.
Ordre DAG / algèbre relationnelle / span
La hiérarchie d'héritage est un ordre partiel acyclique dirigé (484 sous-tables, 374 tables feuilles) ; l'extension ne peut croître que dans le cône inférieur de l'ordre, la duplication par chemins latéraux étant interdite. Les familles de relations r_* / rr_* correspondent respectivement aux relations fonctionnelles et aux spans (1:N / M:N) ; la composition des relations est la composition des morphismes, et les relations hiérarchiques sont gardées par des invariants d'acyclicité.
Mesure signée / additivité
Les stocks et les soldes ne sont pas des attributs d'entités mais des mesures signées additives sur les faits comptables — calculés, non stockés. L'inventaire physique est un événement atomique de correction de mesure ; les excédents et déficits sont absorbés et calibrés comme erreur de mesure normale plutôt que dissimulés.
Instantané à 4 arités
Le découpage de toute transaction le long de son cycle de vie produit le 4-uplet ontologique : Scène Scene (Where & When), Facteur Factor (Who & What), Fonction Function (How) et Statut Status (temps logique discret à sens unique). Trois codes orthogonaux forment un espace ontologique analysable.
Complétude des 5 domaines
Chaque instantané à 4 arités doit couvrir les cinq domaines de transaction — Personne L / Contenant C / Marchandise G / Lieu P / Finance F — sans rupture de symétrie permise, garantissant la boucle métier au niveau du modèle : qui transige, dans quoi c'est transporté, ce qui est transigé, où cela se passe et comment la valeur circule.
Involution miroir event / task
L'axe du temps est partitionné par le « maintenant » en deux moitiés : les events déjà survenus (faits passés) et les tasks non advenus (à-faire futurs) sont miroirs l'un de l'autre ; accomplir une tâche retourne la tranche. Les plans se déploient des deux côtés via des ponts jumeaux — le pilotage par événements et le pilotage par tâches sont les deux directions temporelles d'un même modèle d'entraînement.
Validation du modèle sur plusieurs espaces de noms
Du point de vue de la théorie des modèles : le modèle isahl est la théorie 𝕋, et chaque déploiement sectoriel est un modèle ℳ ⊨ 𝕋. Une même théorie porte déjà 6 espaces de noms, 15 applications, 61 modules, 82 services, 645 coordonnées sémantiques ontologiques — l'intégration d'une nouvelle industrie exige zéro DDL et zéro correctif de modèle : uniquement positionnement par héritage et liaison de coordonnées.
About
L'entreprise
Hangzhou Yuqi Technology Co., Ltd. est une société de logiciels spécialisée dans les agents de construction d'applications d'entreprise. Avec le modèle Alioth développé en propre comme noyau théorique et la plateforme AliothStudio comme vecteur d'ingénierie, elle fournit des solutions de bout en bout — du modèle de données au système métier complet — pour des secteurs tels que la manufacture de commerce extérieur, la logistique et le transport, la navigabilité aéronautique et la gestion de la recherche.
Contrairement aux plateformes low-code traditionnelles qui assemblent des formulaires, la voie de Yuqi est ontologie + construction par agents : le monde métier est d'abord décrit avec précision dans un langage ontologique mathématisé, la structure de la base de données est gelée par la chaîne de publication du modèle (le DDL n'y est produit que là ; les agents ne touchent jamais au modèle de données), puis un pipeline d'agents produit les API backend, les définitions de types et l'interface utilisateur sur cette ontologie — un changement métier est un changement de modèle, et le système évolue avec le métier.
Origine du nom · 名之由来
宇纳万器，器成有度
Le cosmos accueille tous les instruments ; chaque instrument est façonné avec mesure.
Le nom « Yuqi » (Cosmic-Tools) tire son origine de ce vers : le cosmos (宇) accueille tous les instruments (器), et chaque instrument est façonné avec mesure. C'est aussi notre credo d'ingénierie : embrasser la multitude des métiers de l'entreprise et livrer des systèmes qui supportent la mesure et la vérification.
Build What's Next
Aux métiers complexes,
un système qui évolue dans la durée.
Aucun environnement local requis : découvrez en ligne la modélisation, l'assemblage d'applications et l'exécution complète d'AliothStudio — suivez le Livre bleu et construisez votre première application d'entreprise de vos propres mains.
Accéder à l'édition SaaS d'apprentissage →