Program Overview
A multi-year open research initiative designing, building, and validating a privacy-first, fully offline edge AI platform capable of running on low-cost hardware in under-resourced environments. Project Sentinel investigates whether modular, self-healing AI infrastructure can provide meaningful network security, environmental monitoring, and community resilience for organizations (such as medical clinics, small farms, and independent businesses) that operate without dedicated IT personnel, internet dependency, or enterprise budgets.
The system is built as a self-contained core that can be extended through purpose-built research modules: from real-time packet anomaly detection to on-device AI inference (Intel OpenVINO) to smart environmental sensing for precision agriculture and grow environments.
Across 2025-2026 the research thesis sharpened. What began as “modular network security for under-resourced organizations” has been reframed as architectural patience under isolation: how long can infrastructure preserve its core function when permanently cut off from external support, and what architectural patterns make that possible. See Architectural Patience: When Isolation Isn’t an Outage for the thesis paper. The six research tracks remain the work surfaces; the architectural patience thesis is the framing that unifies them. Network security, environmental monitoring, and the other tracks below are concrete instances of one architecture being tested against different signal domains.
6
Research Tracks
v1.0
Core Platform (Sep 2025)
Tracks 2, 5
In Progress
Multi-Year
2025, Ongoing
Current Status
Track 1 Complete · Tracks 2, 5 In Progress · Track 3 Implementation Complete (Pen-test Pending) · Tracks 4, 6 Upcoming
Track Overview
Research Tracks
6 Tracks · Multi-Year (2025, Ongoing)
Core Security Platform
Modular Architecture & Plugin System
Network Services Layer
Edge AI & On-Device Inference
IoT & Environmental Sensing
Field Deployment & Community Validation
The tracks are research surfaces, not a fixed sequential schedule. Progress is opportunistic: the project advances whichever track most directly tests the underlying thesis given current constraints. Track 5 (environmental sensing) moved ahead of Tracks 3 and 4 because the air-quality domain offered a tractable proving ground for the core engine before the harder network case. Upcoming tracks carry no fixed dates for the same reason. Track 6 (field validation) is the gate that turns everything else from "built" into "proven".
Track 1: Core Security Platform
The first track established the foundational security platform: a passive, offline-first network monitoring engine capable of real-time packet analysis, anomaly detection, device fingerprinting, and local threat alerting, all without requiring cloud connectivity or internet access.
Can a fully offline, locally-processed network security system running on a $100 Raspberry Pi 5 match the core detection capabilities of cloud-dependent commercial tools for small and under-resourced environments?
- Built a real-time packet capture and analysis engine using Scapy, designed for high-throughput packet processing on resource-constrained hardware.
- Developed an Isolation Forest-based anomaly detection model that learns normal baseline behavior and flags deviations without requiring labeled threat data.
- Implemented local SQLite storage with automated data retention, archival, and report generation, with no external database required.
- Deployed a local web dashboard with D3.js visualizations for network activity, device inventory, alert management, and security reporting.
- Designed for cross-platform compatibility across Linux x86_64, Raspberry Pi ARM64, and macOS ARM64.
- Targeted a sub-100MB memory footprint to support viability on resource-constrained Pi 5 hardware.
- Core platform development completed September 2025, with v1.0.0 milestone marking the transition to Track 2.
Track 2: Modular Architecture & Plugin System
Track 2 investigates the architecture of a tiered, plug-in module system that allows new research capabilities to be added to the Sentinel core without destabilizing existing functionality. This is the architectural foundation required before any of the advanced tracks can proceed.
How should a long-running, low-maintenance edge system be structured to support modular expansion over a multi-year lifecycle without requiring re-architecture or breaking core stability?
Work Completed
- Designed and implemented a Module Manager with auto-discovery via a standardized module.json schema, including tier enforcement (Lite, Pro, Elite, Ultimate).
- Established CLI commands for module lifecycle management (enable, disable, list, status).
- Architected module isolation so that individual module failure does not affect core system operation, reflecting the design principle of modules as independent, replaceable components.
- Generalized the core detection engine from network-specific to domain-agnostic, enabling signal processing across any sensor domain (network, system, IoT, environmental) through a unified signal schema.
- Built a standardized sensor adapter interface allowing new data sources to be added with minimal code. The interface currently supports network packet analysis, host system metrics, MQTT-based IoT devices, and environmental sensors (temperature, humidity, motion).
Active Work
- Refining cross-module dependency enforcement and validating isolation behavior under failure conditions.
- Exercising the modular architecture in practice through the Track 5 spinoff (Airlume), which uses the platform plugin pattern + adapter interface + signal schema as its foundation. Field experience from Airlume continues to refine the architecture.
- Preparing the module system for deeper network services integration.
Track 3: Network Services Layer
Track 3 extended Sentinel from a passive monitoring tool into a full local network services platform that provides the infrastructure primitives that under-resourced environments typically cannot afford or manage through commercial solutions.
Can a single $100-$200 device serve as a complete, self-managing local network authority (handling DHCP, DNS, VPN, NAS, and time synchronization) with zero ongoing maintenance requirement for non-technical operators?
Implemented Modules
- DHCP Server: local IP management and device identity tracking.
- DNS Sinkhole (enhanced): authoritative DNS with blocking and query logging.
- NTP Server: accurate time synchronization for logging and forensics.
- WireGuard VPN: encrypted remote access without third-party services.
- NAS Module: local encrypted file storage with SMB/NFS access and web UI.
- Certificate Manager: automated TLS certificate generation and renewal.
- SMTP Relay: local email alerting without external mail providers.
- Self-Healing Layer: automatic service recovery and module restart.
- Task Scheduler: cron-like automation for maintenance tasks.
- UPS Monitoring: graceful shutdown and power loss handling.
- Disk Manager: SMART health monitoring and drive failure prediction.
Key Outcomes
- Built 11 self-contained network services, each following a standardized ServiceBase pattern with independent lifecycle management, health reporting, and graceful degradation.
- Implemented a unified web dashboard with per-service management pages, real-time status monitoring, and responsive dark/light theme support.
- Designed edition-tiered feature gating (Lite, Pro, Elite, Ultimate) to support deployment scaling from minimal single-service nodes to full infrastructure platforms.
- All services operate in demo mode on non-Linux platforms, enabling development and testing without target hardware.
- Each service includes comprehensive test coverage (1,400+ tests across all services, 0 regressions).
Track 4: Edge AI & On-Device Inference
Track 4 introduces hardware-accelerated, on-device machine learning inference using Intel OpenVINO, which enables Sentinel to run significantly more capable AI models without cloud processing, GPU requirements, or high-cost hardware.
What is the minimum viable hardware floor for meaningful real-time AI inference (including object detection and behavioral anomaly classification) when using OpenVINO acceleration on an Intel NUC-class device?
Planned Modules & Research Areas
- Integration of the Intel OpenVINO runtime with Sentinel's existing detection pipeline.
- Evaluation of OpenVINO-accelerated models against the current baseline models on identical network traffic datasets.
- Object and person detection via camera input for physical security contexts.
- Visual anomaly detection for server rooms, entry points, and facility monitoring.
- Performance profiling across hardware tiers: Pi 5 vs. SER5 vs. NUC 14 Pro.
- Documenting the "AI cost curve" for community-scale edge deployments.
Track 5: IoT & Environmental Sensing
Track 5 explores Sentinel's expansion into physical environment monitoring, connecting IoT sensors and smart home/agricultural devices to the same local core that handles network security. The goal is to evaluate whether a single Sentinel node can serve as a unified local intelligence layer for both digital (network) and physical (environmental) monitoring.
Concrete output in progress (2026)
The IoT/environmental sensing work has advanced ahead of the original 2027 schedule because the air-quality domain offered a tractable proving ground for the Cortex engine before the harder network case. The Airlume platform is the first concrete instance: MQTT-based sensor onboarding with auto-discovery, real-time multi-room monitoring, learned-baseline trend analysis (CO₂, PM2.5, temperature, humidity), threshold-driven alerting with remediation hints, and a wired Pi sensor publisher (DHT22 now, SCD41 next) that demonstrates the platform working end-to-end with hardware directly on the hub. The first public artifact is the school CO₂ monitoring research demo at Airlume: Improving School Air Quality. Pi field smoke-test is the next validation step before broader deployment.
Can a single offline edge platform provide both network security monitoring and actionable environmental intelligence (such as soil moisture, temperature, humidity, and grow condition tracking) for small farms, greenhouses, and community agricultural sites?
Planned Research Areas
- Integration of DHT22, soil moisture, and light sensors via GPIO on Raspberry Pi 5.
- MQTT broker (Mosquitto) for low-overhead IoT device communication.
- Zigbee / Z-Wave gateway support for commercial smart sensor devices.
- Smart greenhouse module: real-time tracking of soil moisture, ambient temperature, humidity, and light intensity with configurable alert thresholds.
- Automation rules engine: trigger actions (alerts, ventilation, irrigation signals) based on sensor conditions.
- Evaluation of Sentinel's modular architecture as a viable platform for precision agriculture in small-scale and community farming contexts.
- Camera event detection for greenhouse or facility perimeter monitoring.
Track 6: Field Deployment & Community Validation
Track 6 is the validation track. It moves Sentinel from a research and development environment into real-world deployment at partner sites, including clinics, small businesses, and community agricultural facilities.
What are the real-world deployment barriers, failure modes, and support requirements for a privacy-first, offline edge AI system when operated by non-technical users in under-resourced community settings?
Planned Modules & Research Areas
- Controlled deployment at 2-3 partner sites across distinct environment types (clinic, small office, agricultural).
- Longitudinal monitoring of system uptime, alert accuracy, false positive rate, and maintenance events over a 6-12 month observation period.
- Structured user interviews with non-technical operators to evaluate usability, trust, and perceived value.
- Documentation of failure modes, recovery patterns, and self-healing effectiveness in real conditions.
- Publication of deployment findings, hardware recommendations, and a community deployment guide.
This is a living document, updated as each research track of Project Sentinel progresses.
A comprehensive field deployment report with findings and recommendations will be published upon completion of Track 6.
About Project Sentinel
Project Sentinel is built on a single design principle: a local, modular, self-healing security organism built for environments that cannot afford complexity or failure. The system is designed for a 10 to 20 year service life, degrading gracefully rather than hitting a cliff at end of vendor support. The software maintains itself through modules that behave like independent, replaceable biological organs, auto-healing failed services and auto-managing storage, with only the hardware needing periodic refresh. All data stays local. No cloud. No telemetry. No vendor lock-in. Every design decision is made with one user in mind: a busy clinic manager, a small farmer, a solo business owner, someone who needs the system to just work, and never needs to understand why.
Want to discuss this work?
Have questions or want to collaborate? Connect on LinkedIn.
More from: AI Infrastructure
Architectural Patience: When Isolation Isn't an Outage
May 29, 2026
Most engineering treats outage as transient and assumes the disaster ends. This piece asks the question almost no system is designed for: what if outside support never comes back? It makes the case for architectural patience: systems that stay independent by design, degrade gracefully instead of falling off a cliff, and preserve what matters longest, with Voyager 1 as the model.
Read ArticleAI Data Centres: The New Backbone of National Competitiveness
November 19, 2025
Traditional data centres were built for CPU workloads and modest cooling demands — AI has overturned that logic entirely. This article examines how GPU clusters, liquid cooling, and ultra-fast fabrics are redefining data centre architecture, and proposes a three-tier taxonomy alongside a strategic framework to help governments and corporations scale AI infrastructure responsibly.
Read ArticleMesh AI: Toward a Non-Linear Model of Human-Centered Intelligence
April 27, 2026
Most AI systems answer the question you asked. This piece asks whether a system can hold what you have not yet said. A design philosophy on context as a network rather than a queue, and on what understanding would actually require structurally, ethically, and over time.
Read Article