Fractal + AI Overview
Fractal OSI models are machine-readable by design. Every object has an ontological type. Every relationship has a semantic class and structured attributes. That formal structure makes .fractal files exceptionally effective as AI inputs — whether you are generating code, building a RAG pipeline, or querying an organizational knowledge base with a private LLM.
What You Will Find in This Section
| Section | What It Covers |
|---|---|
| Introduction | Why typed, formally structured models outperform raw documents as AI inputs; the .fractal model as a requirements specification |
| Guides | End-to-end code generation from a .fractal file; RAG over Fractal models; querying an org chart with a private LLM; prompt patterns for FML-aware queries |
| Concepts | FML as a typed relational graph; why semantic precision matters for AI performance |
The Core Insight
A .fractal file is not a document — it is a typed relational graph. Every node is an instance of a specific FML class (Entity, Role, Act, FractalSet). Every edge is a typed Associative Class instance (Participation, RoleLink, ActRelationship, ScopeLink). When you feed this structure to an LLM, you are giving it more than text: you are giving it ontological structure that the model can reason about with far greater precision.
This is not theoretical. The Code Generation Workflow guide walks through a complete working example — from a .fractal model to deployed TypeScript interfaces and API routes — using Claude Code and GitHub Copilot.
This structure also makes .fractal models especially resilient as AI inputs over time. Unlike prose specifications that drift as systems evolve, a semantic model remains an accurate description of the domain regardless of what implementation any particular agent generates. The model is the intent; the code is one realization of it. Agents working from a .fractal file have a typed, formally structured contract to work against — making it far less likely that a Customer gets silently reinterpreted as an untyped dictionary, because the model specifies exactly what a Customer is and how it connects to everything else.

