Fractal OSIBeta

Fractal + AI Overview

How Fractal OSI models serve as typed knowledge bases, RAG inputs, and code generation specifications for AI systems.

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

SectionWhat It Covers
IntroductionWhy typed, formally structured models outperform raw documents as AI inputs; the .fractal model as a requirements specification
GuidesEnd-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
ConceptsFML 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.

See Also