System Architecture

Overview

Under the hood, our platform is built on an AI-native, event-driven architecture. Rather than storing static snapshots of your data, the software is engineered around an immutable, chronological log of events. We engineered this system using Event Sourcing and Command Query Responsibility Segregation (CQRS) to decouple data ingestion from state mutation. This guarantees high-throughput write performance and strictly consistent read states across distributed data stores. By pairing AI perception models with a strict human verification gate, the system translates continuous inputs into verified facts—which then automatically trigger updates across your complex inventory and blueprint databases.

Here is how our architecture bridges the gap between physical reality and digital truth.

Data Flow Pipeline

Loading Architecture Diagram...

The operating system is built on a continuous, four-step pipeline that transforms raw physical activity into structured, actionable intelligence.

1. Edge Ingestion & Message Brokering

The ingestion layer processes highly concurrent, asynchronous inputs ranging from high-bandwidth video to low-latency machine telemetry.

• High-Throughput Buffering: Streaming telemetry and external system updates are instantly written to a high-throughput distributed event broker (Redpanda). This buffers the inference pipeline against traffic spikes without data loss, ensuring that sudden bursts of shop-floor activity do not overwhelm the system.
• Efficient Payload Management: Heavy binary payloads (video chunks, CAD files) are routed directly to object storage (AWS S3). The event broker strictly contains the object URI, preventing pipeline bloat and maintaining ultra-fast message delivery.

2. AI Perception & Inference Pipeline

To minimize latency and optimize GPU utilization, the inference engine operates as a distributed computation graph (Ray Serve).

• Multimodal Processing: Audio and video streams are processed through transcription and Vision-Language Models to extract physical context.
• Semantic Structuring: The extracted contexts are processed by a Large Language Model to generate a structured, deterministic event draft. This automatically translates messy physical reality—like a technician swapping a part—into clean digital data.

3. Human-In-The-Loop (HITL) Gateway

To guarantee that lab technicians and engineers do not have to worry about AI hallucinations, a strict human validation gate is enforced before any state is mutated.

• Real-Time Synchronization: Proposed events are pushed to edge devices (tablets, workstations) on the shop floor in real-time.
• Concurrency & Reliability: Strict versioning ensures multiple engineers cannot simultaneously approve conflicting drafts. Upon approval, idempotent routing guarantees that network retries or spotty Wi-Fi on the factory floor do not result in duplicate database entries.

4. Database Architecture & State Mutation

An Event Sourcing model dictates the core data flow. The absolute ground truth is an append-only log of events, while the current system state is treated as a materialized view derived from that log.

A. The Action Event Log (Source of Truth) Ultra-fast, append-only writes are handled by a time-series database (ClickHouse). Every approved action is permanently stored as an immutable record. This eliminates the race conditions and data loss inherent in standard CRUD applications, creating a flawless, unalterable audit trail for every hardware build.

B. Distributed Transactions To update downstream databases without the risk of system lockups, Change Data Capture (Debezium) is employed. This continuously tails the Action Event Log and broadcasts state-mutation commands to the appropriate state databases automatically.

C. Inventory System (Relational) Strict ACID compliance is maintained by a relational database (PostgreSQL) to prevent negative stock values or phantom reads. This ensures that inventory ledgers remain mathematically perfect as parts are consumed or scrapped on the floor.

D. Blueprint System (Graph + Vector) Hardware bill-of-materials relationships are mapped using a graph database (Neo4j), paired with a vector database (Milvus) to store embeddings of CAD files and standard operating procedures (SOPs). This allows the system to instantly link a physical part assembly to its digital twin and historical documentation.

5. Agentic Intelligence & Query Routing

The intelligence layer acts as a unified query engine across the siloed data stores, utilizing an agentic retrieval-augmented generation approach (LlamaIndex). When a complex analytical query is submitted—such as identifying why a specific motor batch is failing QA—the routing agent executes concurrent tasks. It analyzes stock degradation rates in the inventory database, searches for related SOP failures in the vector database, and pulls historical assembly times from the event log. The results are synthesized to deliver highly contextual insights backed by verified mathematical data, enabling engineering teams to make instant, root-cause decisions without manually cross-referencing spreadsheets.