Overview
FrameworX was architected with AI integration as a core design consideration, not an afterthought. This means the fundamental infrastructure—from the object model to the runtime environment—provides the consistency, accessibility, and determinism required for reliable AI integration in industrial systems.
For context on AI applications in industrial automation, see Beyond the Hype: Making AI Work in Industrial Automation.
The Next Integration Frontier
A decade ago, the industry focused on OT-IT integration — connecting operational technology with enterprise IT systems. FrameworX delivered this through native database connectivity, REST APIs, and enterprise protocols.
Now the frontier is OT-AI integration. The same architectural decisions that enabled OT-IT integration — consistent namespaces, managed code, open interfaces — now enable native AI integration. This isn't coincidence; it's the result of building on modern foundations.
Foundation: Consistent Object Model
The cornerstone of AI-readiness is FrameworX's precise object namespace architecture. Every module, property, and relationship follows a consistent model that reflects one-to-one with the solution database.
Why Consistency Enables AI
When AI systems need to understand or generate configuration:
- Queryable structure - AI can interrogate the exact configuration through consistent namespaces
- Predictable relationships - Object hierarchies and dependencies are always structured the same way
- Database reflection - Every runtime object maps directly to its database representation
- Type safety - Strong typing prevents AI from generating invalid configurations
This consistency isn't just convenient—it's essential for AI to reliably interpret and potentially generate valid system configurations. See for the complete namespace structure.
Dynamic Assembly Generation
FrameworX can dynamically compile .NET assemblies at runtime, enabling AI-generated code to execute with full performance and type safety. This isn't interpreted scripting—it's real compilation providing deterministic execution.
Why This Required a Complete Rewrite
FrameworX was built from scratch on .NET rather than retrofitting legacy code. The principle:
"It's like a chain — if you have nine strong links and one weak piece, you break at the weak piece. You need to replace everything."
This decision, to fully embrace .NET rather than wrap older architectures, is what enables the consistent object model, database reflection, and dynamic compilation that make AI integration practical. Platforms that attempt to add AI capabilities on top of legacy architectures face fundamental structural limitations.
Architectural Principles for AI Integration
Deterministic Control, Probabilistic Optimization
The platform maintains strict separation between:
- Control Layer - PID loops, ladder logic, safety interlocks remain deterministic
- AI Layer - Pattern recognition, optimization suggestions, anomaly detection
- Human Layer - Final decisions, override capability, accountability
This separation ensures AI can never directly control critical processes, only provide insights and recommendations.
Event-Driven Architecture Supporting AI
The publish-subscribe model allows AI components to observe without interfering:
- AI models subscribe to relevant data streams
- Process control remains independent of AI processing
- AI results publish to separate namespaces for consumption
- No blocking or delays in critical control paths
The serves as the single source of truth for both control and AI systems.
Current AI Integration Capabilities
Several proven patterns demonstrate the AI-ready architecture in practice:
1. ML.NET Integration for Deterministic ML
Machine learning models that provide consistent, repeatable results for pattern recognition and anomaly detection. Unlike LLMs, these models produce deterministic outputs suitable for industrial applications.
- Time-series anomaly detection
- Predictive maintenance algorithms
- Quality prediction models
- Real compilation through .NET runtime
2. AI MCP Services for Structured LLM Assistance
FrameworX provides two MCP services that expose platform capabilities to AI models through the Model Context Protocol:
AI Runtime — Query Live Data
Connect AI models to running solutions for real-time data access:
- Query tag values from the Unified Namespace
- Retrieve alarm status and history
- Access historian data for trend analysis
- Create custom tools via Script Classes
Use cases: AI-powered dashboards, intelligent troubleshooting, automated report generation from live data.
→ See AI Runtime Connector and AI Runtime Tutorial
AI Designer — AI-Assisted Configuration
Enable AI models to help build and configure solutions:
- Navigate Designer interface
- Create and modify solution objects (Tags, Displays, Alarms)
- Import JSON configurations
- Search and query existing configuration
- Generate XAML for displays
Use cases: Accelerated solution development, configuration validation, bulk object creation, AI pair-programming for industrial applications.
→ See AI Designer Connector and AI Designer In Action
Key Distinction: AI Runtime operates at execution time (live data from TServer.exe). AI Designer operates at configuration time (building solutions in Designer.exe).
3. Documentation AI Helper
The documentation itself was restructured following Diataxis principles specifically to enable AI documentation collaboration. This demonstrates platform-level AI readiness beyond just adding tools.
- Context-aware help based on current task
- Code generation with platform conventions
- Configuration validation and suggestions
4. Local AI for On-Device LLM Integration
FrameworX 10.1.5 ships Local AI — an on-device LLM integrated into the platform. Operators chat from Display panels via the ChatRequest action; server-side scripts call the model atomically with AI.Execute (canonical script API from the T.Toolkit.LocalAI namespace; the legacy TK.AIExecute alias forwards to it) for narration, classification, translation, and summary tasks.
- Zero outbound network traffic — fully local Ollama, no internet connection. Recommended default model:
qwen2.5:7b-instruct(Apache 2.0, ~4.7 GB, best reasoning and tool-call reliability), which expects a GPU. On no-GPU hardware,qwen2.5:3b-instruct(~2 GB) is the fallback for atomic tasks. - Operator chat from Display panels (ChatRequest action)
- Server-side atomic LLM calls from scripts (AI.Execute; legacy TK.AIExecute alias still callable)
- Customer-controllable model and endpoint via SolutionSettings.ModelSettings
→ See Local AI
5. AI Tutor for Interactive Platform Learning
The AI Designer Tutor is a built-in learning companion that runs structured lessons inside live Designer sessions. Forty-five lessons across three tiers (Essentials, Intermediate, Advanced) build from first tag to enterprise architecture — hands-on, adaptive, with progress tracking that survives version upgrades.
- Hands-on by default — every lesson builds working features in a real solution
- Adaptive depth — explains simpler or deeper on request
- Progress survives upgrades — lesson completion tracked per user
- Bundled with AI Designer (ask Claude "teach me FrameworX" in any session)
→ See AI Tutor and Training
Future-Proof Design: These are initial implementations. The architectural foundation supports additional AI tools and patterns as they mature, without requiring platform changes.
Deployment Philosophy
Green Light: Deploy with Confidence
- Historical analysis and trending
- Pattern recognition with deterministic models
- Documentation and knowledge assistance
- Monitoring and alerting
Yellow Light: Human Oversight Required
- Optimization recommendations
- Predictive maintenance scheduling
- Quality predictions requiring verification
- Automated reporting needing validation
Red Light: Not Suitable for Autonomous AI
- Direct control of safety systems
- Emergency response decisions
- Process changes affecting product quality
- Any scenario without human intervention capability
Platform Advantages for AI
.NET Runtime Benefits
- Real compilation - AI-generated code runs at full speed
- Managed memory - Prevents AI-induced memory leaks
- True multithreading - Parallel model execution
- Type safety - Catches errors at compile time
Python Integration
Native interoperability with Python enables use of the entire ML ecosystem while maintaining .NET performance and reliability. See .
UNS as AI Data Foundation
The Unified Namespace provides structured, contextual data access that AI systems can navigate predictably. External analytics integration occurs through .
Key Differentiators
What makes FrameworX truly AI-ready versus platforms with AI add-ons:
- Consistent namespace model - AI can understand the entire system structure
- Database reflection - Configuration is queryable and generatable
- Event-driven architecture - AI observes without interfering
- Documentation designed for AI - Diataxis structure enables intelligent assistance
- Compilation not interpretation - AI code runs deterministically
- Clear separation of concerns - Control remains deterministic
- Two MCP services - Separate tools for runtime data queries and design-time configuration assistance
Related Concepts
- AI Integration — AI Integration features
- Local AI — On-device LLM for chat and script-side AI calls
- AI Tutor and Training — Interactive 45-lesson FrameworX curriculum
- AI Runtime Connector — Query live solution data with AI
- <ac:link><ri:page ri:content-title="AI Designer Connector" /></ac:link> — AI-assisted solution configuration
- AI ML Integration Connector — ML.NET model integration
- Unified Namespace — Data organization for AI access
- Built-in Namespace — Object model consistency
- Scripts Classes Reference — Custom MCP tools via Script Classes
In this section...