Inspiration
I began FDCOS with a conviction: security systems should do more than record what happened after it is already too late.
Today, cameras, alarms, sensors, drones, maps, and monitoring centers often operate as disconnected tools. A camera may detect movement, but it does not understand the perimeter sensor that activated seconds earlier. A drone may provide video, but it usually does not share one operational memory with the camera network. Operators receive dozens of signals and must manually reconstruct the situation while critical time is being lost.
From Santo Domingo, Dominican Republic, I started imagining something larger: a security operating system capable of connecting those isolated resources and turning them into one coordinated intelligence network.
That vision became FDCOS — Figuereo Drone Command Operating System.
FDCOS is not simply a drone controller, surveillance dashboard, alarm system, or isolated AI application. My vision is an autonomous security platform that can perceive an event, correlate evidence, understand its context, evaluate risk, create a mission, select the right resource, preserve evidence, and learn from the result.
Its operating cycle is:
Event → Correlation → Risk → Mission → Dispatch → Evidence → Learning
For OpenAI Build Week, I wanted to solve one of the most important problems inside that vision: when an incident becomes complex, how can the system give an operator a clear, trustworthy, and safe understanding of what is happening?
That question inspired the AI Incident Commander.
I am submitting this project because I believe FDCOS can become much more than a prototype. I want to demonstrate that an ambitious autonomous-security architecture can be developed with transparency, discipline, and safety from the beginning.
What it does
FDCOS integrates cameras, perimeter sensors, drones, ground robots, operational maps, artificial intelligence, communications, and human operators under one coordinated core.
It is designed to connect with existing or future infrastructure, including IP cameras, NVR/DVR systems, RTSP or ONVIF feeds, access-control systems, panic buttons, contact sensors, PIR sensors, infrared barriers, vibration sensors, drones, robots, docks, and authorized communication channels.
Every signal becomes a normalized operational event containing its source, time, location, type, confidence, and state. FDCOS can then correlate related signals using time, space, movement, object identity, zones, historical patterns, and active rules.
The Risk Assessment Engine evaluates not only what was detected, but what that detection means. A person during authorized hours may represent little risk. That same presence inside a restricted perimeter, outside normal hours, and connected to a sensor activation may require immediate attention.
From that context, FDCOS can create missions to:
- Verify an uncertain event
- Follow a person, vehicle, animal, or object
- Search a defined area
- Investigate a perimeter
- Execute adaptive patrols
- Maintain observation across blind spots
- Return or abort because of safety conditions
- Escalate to an authorized human or communication workflow
The broader FDCOS architecture supports deterministic autonomous dispatch when configured thresholds and safety requirements are satisfied. That autonomy is governed by battery, route, connectivity, obstacles, geofences, weather, dock state, resource availability, and abort rules.
The AI Incident Commander, however, is deliberately separated from physical authority.
It reconstructs trusted backend context and produces a structured advisory brief containing:
- An executive summary
- Risk, severity, and confidence
- Priorities
- Safe recommendations
- Facts linked to their provenance
- Uncertainties
- Missing information
- Explicitly blocked actions
It cannot arm a drone, initiate takeoff, start a mission, dispatch real hardware, contact police, trigger an external alarm, or publish a notification. Its purpose is to help people understand an incident—not to give a language model control over it.
FDCOS also includes Property Mapper, Depth Intelligence, SLAM, World Model, fleet management, real-time performance, evidence timelines, and experience-based learning. Its long-term architecture includes a physical Perimeter Hub, autonomous docks, mapper drones for constructing operational knowledge, and lightweight patrol drones that use validated routes and intelligence processed primarily on the ground.
How we built it
FDCOS existed before Build Week as a growing research and engineering platform. Before the competition, I had already developed foundational work involving MAVLink and ArduPilot simulation, telemetry, drone control, Property Mapper, digital twins, visual correlation, depth processing, SLAM, World Model, fleet management, and operator interfaces.
Because the platform crosses robotics, security, computer vision, mapping, backend engineering, frontend design, persistence, and safety, I have collaborated extensively with Codex throughout its development.
During the eligible Build Week period, I meaningfully extended that foundation with a stronger operational event-response workflow and a completely new AI Incident Commander.
GPT-5.6 Sol and Codex helped me inspect the existing repository, find the correct integration boundary, protect the physical-action boundary, and implement the feature through bounded phases:
- A versioned structured advisory contract
- Trusted backend context reconstruction
- Sensitive-data redaction
- A GPT-5.6 provider using the Responses API and Structured Outputs
- Deterministic fallback behavior
- Secure endpoints with authentication, RBAC, ownership, and isolation
- Append-only persistence, idempotency, and sanitized audit records
- A complete Incident Commander workspace
- Backend, frontend, persistence, adversarial, safety, and end-to-end evaluations
- A reproducible demonstration environment with isolated data and no physical effects
I used atomic commits so every phase could be inspected, tested, repaired, and validated independently.
The real GPT-5.6 provider integration exists behind a feature flag. Because competition API credits were no longer available, I refused to fake a live model response. The recorded demonstration transparently identifies that the provider is disabled and uses the deterministic fallback. The demonstration performs zero OpenAI API calls and zero physical or external actions.
That honesty is part of the product design.
Challenges we ran into
The hardest challenge was not generating text. It was integrating generative intelligence into a cyber-physical security architecture without weakening its safety model.
I had to protect the system against arbitrary frontend prompts, prompt injection through operational metadata, cross-owner data leakage, invalid structured output, missing credentials, provider timeouts, refusals, and accidental exposure of coordinates, contacts, camera URLs, evidence, or secrets.
Most importantly, I had to prove that generated recommendations could never become physical commands.
Another challenge was working inside a large platform that existed before the competition. I needed to preserve its architecture, clearly separate prior work from new Build Week development, and create something substantial enough to be evaluated independently.
I also encountered a difficult Windows process issue while preparing the demonstration. Generic development services were replacing the isolated demo backend, causing the browser to use the wrong authentication and persistence configuration. Codex helped trace the problem to process ownership and environment propagation. I then strengthened the launcher so it verifies the exact backend listener, authenticated token, isolated data store, prepared incident, and safety state before declaring the demo ready.
Every challenge reinforced the same lesson: a serious operational system must fail visibly, safely, and truthfully.
Accomplishments that we're proud of
I am proud that FDCOS now demonstrates a complete, traceable chain:
Property → Security Event → Risk Assessment → Response Plan → Incident Record → Commander Brief
The recorded scenario presents a restricted-zone intrusion with high severity, 94% confidence, and a deterministic risk score of 82. The Incident Commander turns that operational state into priorities, recommendations, provenance, uncertainty, missing information, and an explicit safety boundary.
I am especially proud that the interface does not hide limitations. It tells the operator when the AI provider is unavailable. It distinguishes facts from estimates. It shows where information came from. It identifies what is missing. It displays every action that remains outside AI authority.
The implementation passed extensive backend, frontend, authentication, persistence, safety, and end-to-end evaluations. It also includes a reproducible local demonstration that works without a real drone, Unreal Engine, live SITL, proprietary hardware, or an OpenAI API key.
Beyond the code, I am proud that I was able to take a vision this large and present one part of it as a coherent, working product experience.
Winning OpenAI Build Week would mean more to me than receiving a prize. It would validate years of thinking, experimentation, and determination. It would give FDCOS visibility, technical guidance, and the opportunity to move closer to controlled pilots with real organizations.
I genuinely believe this project can grow into something that protects people, properties, infrastructure, and responders.
What we learned
I learned that trustworthy AI requires much more than intelligence.
It requires strict contracts, authenticated context, provenance, uncertainty, privacy boundaries, deterministic fallback, reproducible evaluations, and a clear separation between recommendation and authority.
I learned that autonomous systems and generative AI should not be treated as the same thing. FDCOS can eventually perform deterministic autonomous missions under explicit operational rules, while the Incident Commander remains a separate advisory layer. That separation makes both systems safer and easier to evaluate.
I also learned how powerful Codex becomes when I define the outcome, constraints, safety boundaries, and proof of completion clearly. GPT-5.6 Sol helped reason across a complex repository without losing sight of the larger architectural intent.
Most of all, I learned that limited resources do not have to limit the size of a vision. They require greater discipline, creativity, and persistence.
What's next for FDCOS — AI Incident Commander
The next step is to validate the GPT-5.6 provider with authorized runtime access and expand the evaluation dataset with more incident types, adversarial inputs, provider failures, and multi-source operational scenarios.
From there, I plan to:
- Connect visual correlations directly to persistent Security Events
- Expand camera, sensor, access-control, and perimeter integrations
- Improve camera-to-drone-to-camera continuity
- Advance ArduPilot SITL and Unreal Engine simulation
- Develop the physical FDCOS Perimeter Hub
- Continue designing autonomous docks
- Expand mapper and lightweight patrol-drone workflows
- Build richer evidence timelines and experience-based learning
- Prepare controlled pilot deployments before real-world autonomous operation
FDCOS is designed to grow gradually. An installation can begin with existing cameras and sensors, then add drones, robots, docks, 3D mapping, and advanced intelligence without changing the central operating principle.
My goal is to transform isolated security infrastructure into a coordinated system that can understand events, evaluate risk, mobilize the appropriate resource, preserve evidence, and learn from every operation.
This Build Week submission is not the end of FDCOS. It is the clearest proof I have created so far that the vision can become real.
Built With
- api
- ardupilot
- codex
- fastapi
- gpt-5.6
- javascript
- mavlink
- openai
- outputs
- playwright
- pydantic
- pytest
- python
- react
- responses
- sitl
- structured
- vite
Log in or sign up for Devpost to join the conversation.