Inspiration
Managing real buildings exposed a recurring problem: network, Wi-Fi, communication, and access-control incidents are investigated in fragmented consoles, while corrective actions are often taken without a reliable evidence trail. We started InnerOS Infrastructure Guardian to explore whether an AI system could understand operational infrastructure, recommend safe interventions, and prove whether the problem was actually resolved. Our principle is Cloud intelligence. Local authority. Verified physical actions.
What it does
InnerOS Infrastructure Guardian is a governed Physical AI platform for connected infrastructure. It combines device discovery and telemetry, structured diagnosis, proposed interventions, human authorization, locally executed actions, recovery checks, and evidence receipts. The targeted workflow is Discover → Diagnose → Recommend → Approve → Execute Locally → Verify → Record Evidence. It is designed for environments with equipment from vendors such as UniFi and Grandstream. Read-only monitoring and capability discovery are part of the existing InnerOS foundation. The reboot, PoE-cycle, and recovery capabilities are implemented, registered in the InnerOS Capability Gateway, and covered by automated tests. Production hardware recovery remains a separate verification step.
How we built it
Rather than create another agent platform from scratch, we extended our existing InnerOS stack with Python services, Model Context Protocol (MCP), a provider-aware Device Fabric, and a policy-enforcing Capability Gateway. The hackathon development adds network.device.reboot.v1, network.device.poe_cycle.v1, and network.device.verify_recovery.v1; a structured Nebius/NVIDIA reasoning adapter; input sanitization; dry-run and approval behavior; and a portable demo runner. For the submitted prototype, the verified fallback is a deterministic local heuristic; the separate AMD/Qwen infrastructure is not claimed to have provided model inference for these demo runs. The Nebius adapter is built around a provider interface so cloud inference never receives direct administrative authority over private devices.
Challenges we ran into
Physical infrastructure APIs differ substantially across vendors. Some support management operations and others expose only status or monitoring. We therefore built explicit provider_gap outcomes rather than pretend an action succeeded. Authorization, idempotency, evidence capture, and post-action verification also had to remain separate from language-model recommendations. Another challenge was coordinating development across local agents without losing work during worker timeouts or repository-lock conflicts. A final concern was protecting customer information, so the demo uses sanitized data and avoids exposing production names, addresses, credentials, and device identifiers.
Accomplishments that we're proud of
We extended an existing multi-provider infrastructure platform instead of presenting a disconnected prototype. The implementation includes three governed capabilities, a Nebius Token Factory adapter, a deterministic local fallback, a public Apache-2.0 licensed repository, and a sanitized reproducible demo. Codex recorded 57 passing integration and contract tests, including approval denial, dry-run behavior, unsupported vendors, idempotency, recovery checks, and structured recommendations. These are development-test results, not a claim of completed live deployment or live physical network changes.
What we learned
A model's recommendation is not proof that an infrastructure problem is fixed. Trust requires provider-specific capabilities, clear permission boundaries, measurable before-and-after states, and auditable evidence. We also learned that cloud reasoning can complement local models without giving up the local control plane, and that safe fallback behavior matters as much as optimistic success paths.
What's next for InnerOS Infrastructure Guardian
We connected the presentation interface to the tested Gateway API and documented a functional, isolated lab demo. We have assembled a narrated walkthrough for owner review, and published a sanitized, openly licensed repository with setup instructions and distinguish simulated interventions from authorized hardware operations. Future improvements include topology-aware diagnosis, broader provider support, predictive maintenance, and richer recovery dashboards.
Verified on October 27, 2026: one real inference on Nebius Token Factory using NVIDIA-Nemotron-3-Nano-30B-A3B (308 input tokens, 692 output tokens; completion finish_reason=stop) with a sanitized provider receipt, response ID, and SHA-256 evidence hash. The model analyzed synthetic telemetry, proposed an approval-gated network reboot and recovery verification; no live physical change or hardware recovery is claimed. Public repository: https://github.com/Rafa-Innerchispa/inneros-nebius-nvidia-physical-ai-2026 . Evidence: https://github.com/Rafa-Innerchispa/inneros-nebius-nvidia-physical-ai-2026/blob/main/examples/nebius-live-receipt.json . The public lab UI was deployed and 10 HTTPS smoke checks passed on October 27, including the five real Guardian API routes, simulated verification and the historical real NVIDIA receipt. A temporary Cloudflare Tunnel was used (availability is not guaranteed). Telephone approval was independently demonstrated through the existing InnerOS/Home Assistant/VoiceOps channel, but its link to this Guardian demo has not been verified; no real physical-device remediation is claimed. An edited 97-second narrated walkthrough exists but has not been published as a final official video.
Log in or sign up for Devpost to join the conversation.