Enterprise Application Intelligence · Enterprise Application Building Agent Platform
The cosmos embraces all instruments — each made true to measure
Making intelligence tangible, applications trustworthy — what the AI builds is visible, and every delivered system stands up to measurement and verification.
You describe the business requirements; the AliothStudio platform builds the system. Hangzhou Yuqi Technology constrains its agents with the in-house Alioth data ontology model, freezing the database structure once through the model release chain — the agents never write DDL — and deterministically producing backend APIs, type definitions, and frontend UI on top of that frozen model — delivering not a "looks-usable" demo, but enterprise-grade applications verified by 229 quality gates and ready for production.
The model is open source on GitHub: github.com/CosmicTools9/Alioth · Latest v10.0.44 (2026-10-19)
Solutions
What We Solve for You
Three typical dilemmas of enterprise application construction — and Yuqi's answer to each.
General-purpose agents produce systems that "look complete but can't run"
LLMs invent tables, fields, APIs, and business rules that don't exist; the output looks complete but cannot run — and the hard accuracy requirements of enterprise applications stop most AI-generated tools at the demo stage.
Our answer: constrain the agent with a frozen ontology model — every structural artifact must inherit its location within 645 ontological semantic coordinates and align field by field with machine-readable contracts, so hallucinations are detected and rejected at build time.
Systems assembled from forms can't keep up with business change
Traditional low-code platforms assemble forms, so structures are duplicated along side paths and semantics diverge; the moment the business changes, the system sinks into a swamp where every fix breaks something else.
Our answer: ontology-driven — the business world is first precisely described in a mathematical ontology language; a business change is a model change, and the system evolves together with the business instead of being patched onto old code.
A business system takes months to build, and requirements can't wait
Database design, backend APIs, and frontend UI proceed separately, with integration and rework compounding layer upon layer — by the time the system ships, the business requirements have often moved on.
Our answer: the data structure is frozen once by the model release chain, physically separate from the build chain; the agent pipeline only produces backend APIs, type definitions, and frontend UI — the application layer is generated as one full stack, with zero DDL and zero model patches throughout.
Proven in Production
Already Running in These Industries
The same Alioth model and AliothStudio platform have been deployed across 6 namespaces — 15 apps, 61 modules, 293 Blocks, 82 services (the 6th namespace MAT is onboarding), covering the full chain from inquiry to settlement, from consignment to invoicing.
Integrated order & financial management for foreign-trade garment processing
Covers 18 business scenarios — business overview, customer inquiries, quotations, orders, BOM, procurement, sampling, production, quality inspection, shipment, documentation, receivables/payables, aging, exchange rates, costing, profit, tax rebates, reimbursement, permissions, and settings — connecting the full chain from "inquiry → shipment → settlement".
Logistics & transportation operations management system
Four modules — contracted logistics, transport execution, revenue settlements, and payable settlements — with a built-in "customer ↔ platform ↔ carrier" external collaboration chain and adjudication trace mechanism; unified management of waybills, tracking, geofences, settlement, and invoicing.
Systems R&D & airworthiness management platform
For aviation industry customers: systems R&D management, approval workflows, and airworthiness compliance modules, with ontological modeling of engineers, skill tags, approval roles, and change control boards (CCB).
R&D project master data & budget management
R&D project ledgers, research job-number assignment and re-assignment with audit trail, multi-dimensional project tagging, versioned project-initiation archives, project dependency and fund carry-over relations, and budget-domain plan linkage — zero redundant tables, fully anchored to the unified model structure.
How It Works
How the Platform Works for You
You only need to state your business requirements; AliothStudio's enterprise application building agent does the rest. The platform consists of two independent pipelines: the model release pipeline produces the data foundation, and the application building pipeline assembles your business application on the frozen foundation.
The data foundation itself is maintained by an independent model release pipeline (the sole channel for structure); the agent uses zero DDL throughout the application building pipeline — so the system you receive is always anchored to the same frozen model:
Metadata Platform
The hub for the model's full lifecycle. All structural changes enter the release pipeline only after manual review; the built-in generation engine and agent runtime compile business requirements into application configuration and code artifacts.
Unified Entry
The unified runtime for business applications: it discovers applications automatically and loads extensions (constraints / rules / state machines / workflows), with unified authorization. Each industry system is compiled and deployed independently, without affecting the others.
Single Sign-On
An independently deployed unified authentication service shared by all applications — sign in once, access everywhere.
Collaboration Portal
A portal framework for external collaborators such as customers and suppliers, enabled on demand and independently deployed, sharing the same data foundation as internal systems.
Reliability
Why Reliable: Freeing Agents from LLM Hallucination
The biggest engineering risk of general-purpose agent development is LLM hallucination — the model invents tables, fields, APIs, and business rules that do not exist, producing output that looks complete but cannot run. Yuqi's path is constraining the agent with the ontology model: the LLM only performs requirement understanding and ontology mapping; every structural artifact must be located by inheritance within the frozen ontology space and anchored to machine-readable contracts. Hallucination has nowhere to land under the twin pressure of mathematical structure and engineering gates — meeting the hard enterprise requirements of accuracy and reliability.
Inherit to locate — never invent
The agent's structural actions are confined to the ontology space of the frozen isahl schema: extension may only inherit down-cone along the DAG order and bind three-dimensional ontological coordinates, which are assigned by trigger machinery rather than made up by the model — the LLM cannot invent nonexistent tables or fields, and new industries onboard with zero DDL and zero model patches.
Artifacts align to release-package contracts
Alioth/v* release packages carry machine-readable contracts and verification reports; every agent artifact — module, Block, Service, app.json — must align with the contract field by field. Any hallucinated reference (a dangling service, a nonexistent coordinate) is detected and rejected at build time.
229 mechanically verified gates
The full path from requirement to deployment carries 229 registered gates (137 at commit stage, 92 at push stage): legality of ontological semantic coordinates, integrity of structural references, and compilation/test passage are all machine-judged — relying neither on the care of human reviewers nor on model confidence. Hallucinated artifacts cannot pass the gates into production.
The LLM never generates runtime code
Business runtime logic is deterministically produced by the alioth-gen generator from ontological configuration (APIs, types, UI — no DDL: schema changes only travel through the model release chain); the theoretical core invariants are additionally machine-proven in Lean 4 (zero sorry is a hard push-gate criterion). The LLM only does what it is good at — requirement understanding and mapping choices — while accuracy is backed by structure and proof.
Get Started
How to Get Started
Four ways in, from hands-on to deep: try it online, follow the handbook, read the theory, or audit the code — every claim can be verified by yourself.
SaaS Learning Edition
cosmic-tools.shop offers an online SaaS learning edition of AliothStudio — a streamlined deployment for individual users with the core modeling, application assembly, and runtime flows fully usable; no local environment needed to follow the Blue Paper hands-on.
Builder Blue Paper
"AliothStudio Application Building Handbook": the complete operational path from environment setup, the model center, AppAgent workflows, and the iron rules of module & Service development, to build/deploy and a quick reference of the 229 quality gates.
Theory White Paper
"Alioth Model Theory White Paper": the mathematical foundations of the ontology of exchange — symmetric monoidal categories and groupoid symmetry, coordinate product space, five-domain completeness, conservation measures, multi-namespace model-theoretic validation, and Lean machine proofs of five core metatheorems.
Open-Source Verification on GitHub
The core model is open source at CosmicTools9/Alioth (PLpgSQL · MIT): the latest v10.0.44 (2026-10-19) contains 1022 inherited tables + 268 seed tables, each release verified by a full rebuild in a dedicated validation database — every mathematical property asserted in the white paper has a corresponding structural definition and constraint in the repository.
The application generator CosmicTools9/dsh-alioth (TypeScript): users describe the application in dialogue, and the framework produces AliothStudio-importable artifacts through a deterministic programmatic pipeline — the LLM only supplies structured parameters and semantic decisions, never artifact text. This is the auditable implementation of the "free from LLM hallucination" promise.
Technology
Technical Capabilities
| Capability | Description |
|---|---|
| NGAC fine-grained authorization | A DAG authorization model implementing the NGAC international standard (ANSI/INCITS 565-2022): policy-class multi-tenant isolation, hierarchical inheritance of user/object attributes, association grants and prohibition rules (negative authorization takes precedence), and full audit of policy changes. |
| SQL / AGE intelligent query routing | The backend automatically adapts between relational and graph queries: high-frequency permission checks go through SQL (1–2 ms); multi-hop traversal and shortest paths go through the Apache AGE graph engine. Relational tables remain the single source of truth; AGE is an optional acceleration layer. |
| AI-driven application generation | The AppAgent runtime drives the automated chain "requirement → prototype → ontology mapping → module / Block / Service artifacts" with a state machine; the EmpAgent knowledge-injection pipeline keeps domain knowledge symmetric and complete. |
| Lean 4 formal verification | The theoretical core invariants (value conservation, involution structurality, completion termination and correctness, decidability of five-domain completeness) are machine-proven in Lean 4, with zero sorry as a hard criterion for the code-push gate — mathematical correctness is verified by the prover, not endorsed by review. |
| Distributed identity & audit | Business data uses distributed unique IDs (zuid); all operations land in an independent audit schema, enabling end-to-end traceability together with the transaction symmetry model. |
| Integrated release pipeline | Meta-generated artifacts → namespace build → release deployment package (binary + DDL + docker-compose + ops scripts); the gateway restarts automatically in the production phase, and the release process is closed-loop and rollback-capable. |
| Modern tech stack | Backend in Rust (high performance, memory safety); frontend in React + TypeScript; database PostgreSQL + Apache AGE graph extension; engineering based on pnpm / Cargo workspace modular monolith. |
Theory
Theoretical Foundation: The Alioth Data Ontology Model
Why can this model constrain the agent? Because Alioth is an enterprise-grade data ontology modeling framework built on category theory and the principle of symmetry: economic behavior is formalized as morphisms in the exchange category, reversible transactions form the core groupoid, and symmetry is strictly characterized by an involutive endofunctor — every transaction has a unique mirror-image inverse, guaranteeing value conservation and structural integrity. All mathematical invariants are anchored to engineering gates, and the core theorems are machine-proven in Lean 4. The model is open source: github.com/CosmicTools9/Alioth.
Category / Groupoid / Involutive Endofunctor
Transactions are morphisms in the exchange category 𝓔; reversible transactions form the core groupoid core(𝓔); symmetry = an involutive endofunctor S : core(𝓔) → core(𝓔)ᵒᵖ with S² = id. Engineering consequence — the mirror transaction exists uniquely and value conservation is witnessed per entry: every voucher records opening and closing balances, so "prior state + net change = posterior state" is mechanically verifiable line by line.
Product Category / Coordinate Functor
The coordinate functor χ = (dk_scene, dk_factor, dk_function) locates every business entity at a unique point in the S × F × U product category: the three dimensions are orthogonal, take values independently, and evolve independently; dimension codes are hierarchical addresses assigned by trigger machinery, not by human convention.
DAG Order / Relational Algebra / Span
The inheritance hierarchy is a directed acyclic partial order (484 subtables, 374 leaf tables); extension may only grow down-cone along the order, and side-path duplication is forbidden. The r_* / rr_* relation families correspond to functional relations and spans (1:N / M:N); relation composition is morphism composition, and hierarchical relations are guarded by acyclicity invariants.
Signed Measure / Additivity
Inventory and balances are not entity attributes but additive signed measures over voucher facts — computed, not stored. Stocktaking is an atomic measure-correction event; surpluses and deficits are absorbed and calibrated as normal measurement error rather than concealed.
4-Arity Snapshot
Slicing any transaction along its lifecycle yields the ontological 4-tuple: Scene (Where & When), Factor (Who & What), Function (How), and Status (discrete logical time advancing in one direction). Three orthogonal codes form a parseable ontology space.
Five-Domain Completeness
Every 4-arity snapshot must cover the five transaction domains — Person L / Container C / Goods G / Place P / Finance F — with no symmetry breaking allowed, guaranteeing business closure at the model level: who transacts, in what it is carried, what is transacted, where it happens, and how value flows.
event / task Mirror Involution
The timeline is partitioned by "now" into two halves: events that have happened (past facts) and tasks that have not (future to-dos) mirror each other; completing a task flips the slice. Plans unfold toward both sides across twin bridges — event-driven and task-driven are the two temporal directions of one driving model.
Multi-Namespace Model Validation
From a model-theoretic view: the isahl model is the theory 𝕋, and each industry namespace deployment is a model ℳ ⊨ 𝕋. One theory already carries 6 namespaces, 15 apps, 61 modules, 82 services, and 645 ontology semantic coordinates — onboarding a new industry requires zero DDL and zero model patches, only inheritance positioning and coordinate binding.
About
About Us
Hangzhou Yuqi Technology Co., Ltd. is a software company focused on enterprise application building agents. With the in-house Alioth model as the theoretical core and the AliothStudio platform as the engineering vehicle, the company delivers end-to-end solutions — from data models to complete business systems — for industries including foreign-trade manufacturing, logistics & transportation, aviation airworthiness, and research management.
Unlike traditional low-code platforms that assemble forms, Yuqi's path is ontology-driven + agent-built: the business world is first precisely described in a mathematical ontology language, the database structure is frozen by the model release chain (DDL is produced only there — agents never touch the database model), and an agent pipeline then produces backend APIs, type definitions, and frontend UI on that ontology — a business change is a model change, and the system evolves together with the business.
Name Origin · 名之由来
宇纳万器，器成有度
The cosmos embraces all instruments — each made true to measure.
The name “Yuqi” (Cosmic-Tools) stems from this verse — the cosmos (宇) embraces all instruments (器), and every instrument is made true to measure. It is also our engineering creed: embrace the myriad forms of enterprise business, and deliver systems that stand up to measurement and verification.
Build What's Next
Give complex business
a system that keeps evolving.
No local environment needed — experience AliothStudio's full modeling, application assembly, and runtime flow online, and follow the Blue Paper to build your first enterprise application yourself.
Try the SaaS Learning Edition →