InnerOS FieldOps

Real AI. Real Places. Real Impact.
From Infrastructure to Communities.
From Observation to Action
From Voice to Action
From Infrastructure to Peace of Mind
From Real-World Needs to Real Results

Final Build Update — September 14, 2026

InnerOS FieldOps is now video-ready with the final authenticated Judge Console deployed.

Latest verified build:

Deployed commit: 4755b635455a3599956d2359d1ef78c23d43c7d8
71 pytest tests PASS
compileall PASS
git diff --check PASS
Authenticated Judge Console live
Server-side username/password login with signed session cookie
Unauthenticated public access fails closed
Homogeneous operator UI for Security, Solar, Network, Alarm and Telephony
Normalized runtime states: READY / DEGRADED / BLOCKED / OFFLINE
Explicit evidence labels: REAL / CAPTURED REAL / SYNTHETIC
Judge Mode for the complete approval → execution → verification → Evidence Receipt story

Judge Panel: https://inneros.creatorcore.ai/app/judge

The temporary judge credential is configured server-side and is intentionally not published in the repository or project description.

Judge Testing Instructions

Open the authenticated Judge Console at:

https://inneros.creatorcore.ai/app/judge

Use the judge credentials provided privately by the project owner. Credentials are configured server-side and are not stored in the public repository.

Recommended evaluation flow:

Sign in to the Judge Console. Confirm the unified status strip and the five operational domains: Security/Camera, Solar/Energy, Network/Facility, Alarm/Security Panel and Telephony/PBX.
Run Read Solar. Review the Xmart/Pi01 telemetry, source label, timestamp/freshness, verification result and evidence receipt. This path is read-only; no inverter write operation is exposed.
Run Scan Wi-Fi. Review the sanitized RF/network evidence and confirm that FieldOps verifies Ethernet route integrity before and after the scan. No RF mutation is performed.
Run Read Alarm. Review the real Home Assistant/Intelbras panel state and zone summary. FieldOps intentionally does not expose arm/disarm/panic/siren/PGM controls.
Run Read PBX. Review VoiceOps/Grandstream PBX control-plane health. FieldOps does not register SIP, read SIP secrets or originate arbitrary calls. Audible owner-side call confirmation is not claimed while the current VoiceOps endpoints remain unavailable.
Open the Security/Judge workflow and first choose the deny path. Confirm that the executor remains blocked when human approval is denied.
Run the approved Security path. Follow the complete governed sequence: Observe → Analyze → Approve → Bounded Execute → Independent Verify → Evidence Receipt.
Inspect the Evidence Receipt and final quality gate. A successful command ACK is not accepted as success; FieldOps requires independent state verification.
Review source labels throughout the console. REAL, CAPTURED REAL and SYNTHETIC evidence are explicitly distinguished.
Log out to confirm the authenticated session boundary. Unauthenticated public observations fail closed by design.

For local reproduction, clone the public repository and follow the README setup instructions. The working judge build uses the real Strands Agents SDK runtime with local/private InnerOS execution. The repository also includes an AgentCore-oriented entrypoint and optional Amazon Bedrock provider configuration. Live Bedrock inference is not claimed in the final submission because the AWS account returned ValidationException: Operation not allowed during final testing.

Inspiration

Most AI agents stop at advice. Real operations do not. Facilities teams, managed-service providers, security integrators, installers, and field technicians lose hours coordinating incidents across dashboards, devices, approvals, phone calls, physical systems, and follow-up. InnerOS FieldOps closes the gap between knowing what should happen and safely proving that it happened.

What it does

InnerOS FieldOps is a governed Professional Agent for real-world operations, built with the Strands Agents SDK.

Its operating loop is:

Observe → Analyze → Approve when required → Bounded Execute → Independently Verify → Evidence Receipt

The Judge Console presents every capability through the same operational model so judges can immediately understand what is real, what is read-only, what requires approval, what executed, and what was independently verified.

Read-only observations do not require fake approval theater, but they still use allowlisted targets, bounded observers, verification and auditable receipts. Consequential mutations require human approval and cannot be considered successful until independent post-action readback confirms the requested state.

A backend ACK is never accepted as proof of success by itself.

Who it is for

FieldOps is designed for professionals who already know their work but lose time coordinating it: managed IT providers, security integrators, maintenance teams, facilities operators, network installers, smart-building companies, and other field-service organizations where work crosses software and physical infrastructure.

Final Judge Console

The final authenticated console has one unified visual language and five operational modules:

1. Security / Camera

The security scenario demonstrates the full governed action lifecycle:

incident → Strands analysis → bounded proposal → human approval → execution → independent verification → Evidence Receipt

The judge can also run the denial path and see the executor remain blocked. The hackathon security execution fixture is explicitly labeled synthetic where appropriate, so synthetic evidence is never presented as production camera control.

2. Solar / Energy — real read-only evidence

An InnerOS Raspberry Pi Edge Node is physically connected over USB to an Xmart/PI30-compatible inverter. energy.read_status reads the existing telemetry path without exposing inverter write operations.

The console can show operating mode, grid voltage, battery voltage/capacity, output power and load, PV charging data, inverter temperature, timestamp/freshness and source/evidence classification. The safety contract remains read-only.

3. Network / Facility — real infrastructure evidence

network.scan_wifi uses the existing edge networking path and verifies that the production route remains on Ethernet before and after the RF observation. No RF mutation is exposed to the agent.

The console presents sanitized network evidence with source, verification and evidence receipt in the same structure as the other modules.

4. Alarm / Security Panel — real read-only evidence

The Judge Console reads the existing Home Assistant / Intelbras Guardian projection and reports the real alarm panel and zone state.

It shows panel state, zone count and open-zone summary. FieldOps does not claim arm/disarm/panic/siren/PGM control in this submission because no bounded executor + independent readback has yet been proven for those actions.

5. Telephony / PBX — real control-plane evidence

FieldOps reads the existing VoiceOps service and an independent Grandstream/Asterisk PBX control-plane probe.

The console verifies that VoiceOps status is visible, the private PBX control plane is reachable when available, FieldOps does not register another SIP endpoint, FieldOps does not read SIP credentials, and FieldOps does not originate arbitrary calls.

The PBX/read-only status path is real. Audible owner-side Zoiper call confirmation is not claimed in the final FieldOps build while the current VoiceOps endpoints remain unavailable. Call execution stays owned by VoiceOps until its governed execution/verification contract is healthy.

Real physical mutation already proven

Home Assistant bounded control

FieldOps controls only explicitly allowlisted, noncritical Home Assistant devices. A real physical cycle was executed through FieldOps: proposal generated under central policy; explicit approval artifact accepted; physical state changed; independent Home Assistant readback converged to the requested state; Evidence Receipt returned quality_gate=passed.

Testing exposed real asynchronous state propagation: when Home Assistant had not yet converged, FieldOps failed closed even though the service ACK succeeded. The verifier was then improved with bounded polling. The important point is that FieldOps refused to call the action successful until the physical state could actually be verified.

DMX / lighting

FieldOps reuses the existing InnerOS AG-59 Art-Net/DMX runtime. Only allowlisted scenes and blackout are exposed; raw universe/channel writes are not. A real scene and blackout were executed and independently verified.

Authentication and public demo safety

The Judge Console has real login/logout with credentials configured only on the server. Sensitive endpoints require an authenticated session. Public unauthenticated observations fail closed.

Authentication is not cosmetic: it allows the judge-facing surface to expose bounded operational observations while preserving the local/private execution boundary and keeping infrastructure credentials out of the browser and repository.

Strands Agents

Strands Agents is genuinely integrated as the orchestration layer. The final Judge Console is mediated by a real strands.Agent runtime with bounded FieldOps tools.

FieldOps keeps agent reasoning, policy, human approval, executor, independent verifier and Evidence Receipt as explicit boundaries.

The repository also includes an AgentCore-oriented entrypoint and an optional Amazon Bedrock provider path.

We do not claim successful live Bedrock inference in this final build because the AWS account returned ValidationException: Operation not allowed during final testing. The working demo remains real Strands orchestration with local/private execution and verification. Bedrock remains an optional route once the AWS account restriction is resolved.

Architecture

Human / Event / Alert → Strands Agent → InnerOS FieldOps Policy + Context → Human Approval Gate when required → Governed Executor or Read Observer → Independent Verifier → Evidence Receipt → Audit Replay

FieldOps deliberately separates cloud intelligence from sovereign execution. Device credentials and physical control remain behind local/private boundaries.

Safety and trust

FieldOps follows these hard invariants:

No arbitrary model-generated shell execution.
No arbitrary physical or network targets.
No consequential mutation without the required approval artifact.
No successful mutation without independent verification.
Read-only observations are bounded and verified.
Device credentials remain with the owning subsystem whenever a capability is reused.
Unknown, unavailable or unbound operations fail closed.
REAL, CAPTURED REAL and SYNTHETIC evidence are explicitly distinguished.

Final verification

Final pre-submission evidence:

71/71 pytest PASS
compileall PASS
git diff --check PASS
login/logout PASS
unauthenticated public access FAIL-CLOSED as designed
authenticated Solar observation PASS
authenticated Wi-Fi observation PASS
authenticated Alarm observation PASS
authenticated PBX observation PASS
Security denial path PASS
Security approved path PASS
bounded execution PASS
independent verification PASS
Evidence Receipt quality gate PASS

Why it matters

Professionals often spend more time coordinating systems than doing the technical work itself. FieldOps moves repetitive observation, coordination, evidence gathering and safe execution to the agent while keeping humans in control of meaningful decisions.

InnerOS has historical internal evidence from one workflow moving from approximately 120 human minutes to approximately 10 assisted minutes. We treat that as one internal measurement, not a universal benchmark.

The broader metric is Human Time Returned: reduce routine coordination without replacing human judgment.

What makes it different

FieldOps is not another chatbot, generic dashboard or cloud-only AIOps demo. It combines real Strands agent orchestration, human authority for consequential actions, real physical mutation with independent state verification, live read-only evidence from solar/network/alarm/camera/telephony infrastructure, one homogeneous judge-facing operational console, server-side authentication and fail-closed public access, sovereign local/private execution, reuse of existing InnerOS capabilities rather than duplicating device clients and secrets, auditable Evidence Receipts, and explicit truth labels across real and synthetic evidence.

Cloud intelligence. Sovereign execution. Verified outcomes.

Built With

amazon-bedrock
amazon-bedrock-agentcore
amd-rocm
ami
art-net
dmx
grandstream-ucm6104
home-assistant
inneros
mcp
python
raspberry-pi
sip
strands-agents-sdk
unifi
vllm

Submitted to

Agents for Humans Hackathon

Created by

I led the end-to-end design, integration, debugging, and delivery of InnerOS FieldOps, turning the project from an idea into a working agentic system connected to real-world operational infrastructure.

My main contribution was building the bridge between AI reasoning and physical systems. I designed the workflow around a strict operating model: observe the environment, understand the situation, request human approval when required, execute only a bounded action, independently verify the result, and create an auditable Evidence Receipt.

The hardest part was not building a chatbot. It was making multiple real systems behave as one trustworthy platform.

We had to integrate and normalize evidence coming from cameras, solar infrastructure, a Raspberry Pi edge node, Home Assistant, UniFi networking, security systems, and communications infrastructure. Each system had different protocols, reliability characteristics, authentication requirements, and safety boundaries.

Several problems appeared during development. Real hardware was not always reachable, network conditions changed, remote access was unreliable, and some integrations had to work while I was traveling and operating over unstable Wi-Fi. Instead of hiding those limitations, I designed FieldOps to distinguish between live, captured-real, and synthetic evidence, so judges can always understand exactly what they are seeing.

A second major challenge was safety. It would have been easy to make the demo look impressive by allowing unrestricted commands. I deliberately chose the opposite architecture. High-impact actions fail closed, arbitrary shell or network execution is not allowed, and a successful command is not considered a successful outcome until an independent verifier confirms the physical or system state.

I also integrated the project with the Strands Agents SDK, replacing an earlier documentation-level integration with a real strands.Agent runtime and a bounded execution tool. The final Judge Console passed 22/22 tests, compilation checks, browser validation, the approved execution path, independent verification, Evidence Receipt generation, and a denial path that correctly stops execution when approval is refused.

AWS Bedrock created another challenge. Account authorization prevented us from proving a live Bedrock inference before submission. Rather than fabricate a cloud demo, I kept the architecture local-first and continued with the fully verified Strands execution path, while preserving Bedrock as an optional cloud-intelligence layer.

Finally, I worked across the entire delivery process: architecture, backend integration, safety design, testing, Judge Console, technical documentation, evidence, demo preparation, and submission storytelling.

The result is more than a hackathon prototype. We proved that AI agents can safely participate in real-world operations while keeping humans in control and preserving evidence of what actually happened.

InnerOS FieldOps became a working demonstration of cloud intelligence, sovereign execution, and verified outcomes.

Rafael Lopez
AI Infrastructure & Automation Entrepreneur. Founder of InnerChispa. I build sovereign multi-agent systems and enterprise integrations.

Updates

Rafael Lopez started this project — Sep 13, 2026 12:46 AM EDT

Leave feedback in the comments!

Log in or sign up for Devpost to join the conversation.