Ayizan AI: The Operational Twin

The Inspiration: The Black Box of Facility Operations

To survive and scale, business and facility managers need an integrated co-pilot capable of governing their operations both physically and financially. Running any commercial facility means operating on razor-thin margins while constantly fighting invisible, silent threats. Managers are often completely blind to what is happening behind the scenes until equipment actually breaks down. A silent voltage drop, an unbalanced load, or a struggling compressor doesn't just waste energy—it destroys thousands of dinars in heavy infrastructure, ruins critical inventory, and quietly wipes out weeks of operational profit.

We built Ayizan AI to solve this exact problem. It is an autonomous, air-gapped AI engineered to monitor and optimize the entire physical and financial ecosystem of a facility. Acting simultaneously as a Chief Engineer and a Financial Analyst, Ayizan AI operates on two core mandates:

Physical Infrastructure Protection: Monitoring and predicting hardware catastrophes before they happen. By streaming real-time data from either our custom electric measuring unit or any third-party sensor hardware, the AI actively anticipates physical failures and provides exact, step-by-step fixes using RAG-injected engineering manuals.
Economic & Financial Intelligence: Managing and analyzing the daily financial ledger. It ingests daily facility income, subtracts active operational and energy costs, and performs real-time margin analysis to ensure the business turns a profit.

The Solution: Ayizan AI

Existing cloud dashboards plot graphs, but they require expensive SaaS subscriptions and stable internet—luxuries edge environments cannot afford. Facility managers do not need another graph; they need a system that translates physical hardware states directly into financial impact in their native dialect.

Ayizan AI acts as an autonomous Chief Engineer on a flash drive. The software layer is completely hardware-agnostic: while it includes an optional custom-built electric measuring unit, it seamlessly integrates with any existing third-party energy meter, IoT gateway, or industrial telemetry unit. Raw hardware streams feed into two equally critical pillars:

The Physics Engine: Actively diagnoses thermal and electrical anomalies—detecting a struggling compressor motor or phase imbalance before it causes catastrophic failure.
The Business Intelligence (BI) Engine: Ingests daily sales and operational inputs, cross-referencing them against real-time physical power consumption to deliver precise offline financial recaps.

Data Ingestion & Processing Architecture

┌─────────────────────────────────────────────────────────┐
│                 DATA INGESTION SOURCES                  │
├──────────────────────────┬──────────────────────────────┤
│  Hardware Telemetry      │  Business & Ledger Data      │
│  • Custom Electric Unit  │  • Daily Sales Inputs        │
│  • 3rd-Party IoT Meters  │  • Operating Expenses        │
│  • Modbus / MQTT / HTTP  │  • Utility Rates & Fines     │
└────────────┬─────────────┴──────────────┬───────────────┘
             │                            │
             ▼                            ▼
┌─────────────────────────────────────────────────────────┐
│               LOCAL PROCESSING PIPELINE                 │
├─────────────────────────────────────────────────────────┤
│ 1. Local Ingestion Layer (SQLite Buffer / Normalizer)   │
│ 2. Physics Engine (Thermodynamic & Electrical Logic)    │
│ 3. BI Engine (Capital Ledger & Real-Time Margin Calc)   │
│ 4. Vector DB & RAG Pipeline (Technical Manual Retrieval)│
└────────────────────────────┬────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────┐
│             REASONING & EXECUTIVE OUTPUT                │
├─────────────────────────────────────────────────────────┤
│ • llama.cpp Engine (Qwen 3B Q4_K_M GGUF Model)          │
│ • Deterministic Python Formatting Interceptor           │
│ • Unified Dashboard (Green/Yellow/Red Diagnostics)      │
│ • Actionable Physical Fixes & Real-Time Financial Recaps│
└─────────────────────────────────────────────────────────┘

System Architecture

To make enterprise-grade AI run on budget hardware, we built a strictly decoupled microservices architecture:

Hardware-Agnostic Sensor Integration: Reads telemetry from custom hardware or standard off-the-shelf 3rd-party energy meters via local API endpoints, buffering raw voltage, current, and temperature data directly into a local SQLite database.
The Physics Engine (State Machine): A deterministic Python layer applies relational thermodynamic logic (e.g., detecting if a cooling unit is pulling Locked Rotor Amperage while temperatures rise).
The BI Engine (Capital Ledger): Processes revenue inputs against energy consumption, calculating active margins, daily energy-to-revenue ratios, and operational overhead without external network calls.
The Dual-Search RAG Engine: Uses the Nomic embedding model to vectorize active hardware anomalies and retrieve specific engineering protocols from a localized JSON vector database.
The Reasoning Core (llama.cpp): Runs an aggressively quantized 3-Billion parameter reasoning model (Q4_K_M GGUF format) with a ~2.5GB memory footprint, executing high-speed inference on a standard 15W Intel CPU without requiring a GPU.

Engineering Challenges

The Edge Hardware Wall: Constrained to an older Intel i5 processor with an 8GB RAM ceiling, initial Time-To-First-Token (TTFT) exceeded 45 seconds.
The Fix: We implemented a custom Semantic KV-Caching system. Keeping heavy database context static in the prompt prefix allows the C++ backend to cache neural computations in RAM, dropping latency under 10 seconds.

The Translation/Hallucination Trap: Forcing the 3B model to simultaneously parse data, reason, and translate everything into regional dialects overwhelmed its context window, causing severe hallucinations.
The Fix: We established a strict "Format In, Format Out" pipeline. Core reasoning executes in English to preserve logical fidelity, while localization and final formatting are handled by a deterministic Python interceptor before rendering to the user interface.

What We Learned

Smarter context structuring beats larger parameter counts. A 3B parameter model, when supplied with structured highly optimized physical and financial data, reliably outperforms unconstrained cloud models on domain-specific edge tasks. We optimized llama.cpp memory allocation, mitigated CPU power-throttling on legacy hardware, and built robust local API pipelines.

What's Next

IoT Actuation & LoRA Fine-Tuning.
Targeted Model Fine-Tuning & Conversational Persona: Train domain-specific adapters (LoRA) on base model weights to improve diagnostic precision, root-cause reasoning, and structured output accuracy. Simultaneously refine the LLM's chatting personality and expand multi-language capabilities to deliver a tailored, intuitive user experience for global operators.

Enterprise & 3rd-Party Telemetry Ingestion: Scale the platform beyond isolated setups by building plug-and-play connectors for third-party telemetry protocols, enabling seamless deployment across different business verticals.