Nova A.R.C. Command Center
Inspiration
We were inspired by a simple gap in most AI demos: they can explain, summarize, and recommend, but they rarely operate like a real command center.
In real operations, whether it is a cold-chain warehouse, a grid operations team, or any future mission-critical environment, the problem is not just understanding an incident. The real challenge is to:
- Detect what is happening.
- Ground it with the right evidence.
- Decide what should happen next.
- Execute only the actions that are allowed.
- Verify whether the incident is actually contained.
- Leave a replayable audit trail for trust and accountability.
That led us to build Nova A.R.C. Command Center.
Our core idea was to turn Amazon Nova into more than a chat interface. We wanted to build a pack-driven agentic harness that behaves like a configurable command-center brain. Instead of creating a separate app for every industry, we designed one stable runtime that can load different mission packs, directives, tools, and verification policies.
The hero use case we chose was cold-chain incident response, because it is easy to understand, high-stakes, visually demo-friendly, and a strong example of real-world operational impact.
What it does
Nova A.R.C. is a voice-first, multimodal incident command center built on Amazon Nova.
It is designed to:
- Ingest an operational incident.
- Ground it with multimodal evidence.
- Plan the next best actions.
- Execute approved tools.
- Verify whether the desired outcome was achieved.
- Present the full replay in a command-center UI.
Our primary demo use case is ColdChain Live.
Example incident:
"Zone B temperature is above threshold. Batch VX-204 may be affected. Shipment SHP-884 is loading now."
The system then:
- Interprets the incident.
- Retrieves supporting evidence such as SOPs, logs, screenshots, and prior incidents.
- Generates a strategy.
- Performs actions like quarantine, shipment hold, and notifications.
- Verifies the result.
- Shows a replay timeline and residual risk.
We also included a secondary Grid Ops pack to prove that the same harness can be reconfigured for another operational domain without rewriting the core architecture.
At a high level, the engine follows this loop:
$$ \text{Observe} \xrightarrow{} \text{Ground} \xrightarrow{} \text{Plan} \xrightarrow{} \text{Act} \xrightarrow{} \text{Verify} \xrightarrow{} \text{Replay} $$
And the core architectural idea is:
$$ \text{Same Harness} + \text{Different Pack} = \text{New Command Center} $$
How we built it
We built Nova A.R.C. around a mission harness architecture. Instead of hardcoding workflows for each use case, we separated the system into a stable core, replaceable bridges, and mission packs.
1. Stable Core
MissionProfilePackLoaderMissionHarnessPolicyEngineReplayStoreVerifierToolRegistrySurfaceAdapter
2. Replaceable Bridges
BedrockConverseBridgeNovaSonicBridgeMultimodalEmbeddingBridgeNovaActBridge
3. Mission Packs
cold_chaingrid_ops
This gave us a reusable structure where the runtime stays stable, while the mission-specific behavior changes through packs, tools, policies, and bridges.
For the frontend, we used Streamlit to build a fast, filmable command-center UI featuring:
- Mission header
- Prime directive
- Runtime mode
- Evidence cards
- Strategy and action plan
- Execution panel
- Verification panel
- Replay timeline
- Debug visibility for planner output and bridge health
We designed the project around Amazon Nova-native capabilities:
- Amazon Bedrock + Nova for reasoning, planning, and strategy generation.
- Nova 2 Sonic as the voice interaction path.
- Nova Multimodal Embeddings as the grounding layer for evidence retrieval.
- Nova Act as the browser workflow automation bridge for future UI-driven actions.
Even where some capabilities are currently bridge-backed or staged for live integration, the architecture was intentionally built so Nova is the intelligence layer at the center of the system.
Challenges we ran into
This project was much harder than building a normal AI demo.
Moving from “AI answers” to “AI operations”
It is relatively easy to generate a summary or a recommendation. It is much harder to build a system that:
- Plans safely.
- Uses only allowed tools.
- Avoids cross-domain leakage.
- Verifies outcomes.
We had to think carefully about policy gating, tool restrictions, and verification so the system would feel trustworthy.
Making the live planner stable
A major challenge was ensuring that live model output always fit the internal plan schema. In demo mode, everything is deterministic. In live mode, the planner can return unexpected or incomplete output.
We had to tighten:
- Structured planner prompts
- Parsing and validation
- Fallback handling
- Debug visibility
- Tool scoping by mission pack
Avoiding cross-pack tool leakage
Because the harness can support multiple packs, we discovered an important problem: the planner must only see tools that are allowed for the active mission. Otherwise, it may choose a valid tool from the wrong domain.
That forced us to improve:
- Pack-scoped tool exposure
- Plan sanitization
- Policy validation
- Explicit failure handling
Balancing realism with demo reliability
We wanted the project to feel close to real, but also be stable enough to film and present confidently. That meant making careful decisions about:
- What should be fully live.
- What should be bridge-backed.
- What should be simulated safely.
- What should be made visible in the UI for trust.
Accomplishments that we're proud of
We are most proud that Nova A.R.C. feels like a system, not just a demo.
We built:
- A reusable pack-driven harness.
- A command-center style UI.
- A policy-aware decision loop.
- A verification layer instead of blind tool execution.
- A replayable incident timeline.
- A structure that can expand into multiple operational domains.
We are also proud that the project demonstrates a strong product idea: instead of rebuilding a new app for every industry, we can configure the same runtime with different mission packs.
Today it supports:
- Cold-chain operations
- Grid operations
Tomorrow it can expand into:
- Airport disruption response
- Warehouse exception handling
- Telecom operations
- Industrial response workflows
- Other future command-center environments
What we learned
We learned that building an agentic system is not mainly about prompts. It is about interfaces, controls, and feedback loops.
A strong agentic system needs:
- A normalized world state
- Clear mission directives
- Constrained tool access
- Policy-aware decision making
- Verification after action
- Observability at every step
We also learned that multimodal grounding matters much more than we expected. A command center becomes significantly more useful when it can connect voice, logs, documents, images, and prior incidents into a single operational view.
Finally, we learned that the most convincing AI product is not the one with the flashiest output. It is the one that makes people feel:
"I understand what happened."
"I see why it chose this action."
"I trust the guardrails."
"I can replay the outcome."
What's next for Nova A.R.C. Command Center
The next step is to push Nova A.R.C. closer to a truly live operational system.
Our immediate roadmap is:
- Strengthen the ColdChain Live hero flow so it is fully stable for real-world demoing.
- Make the live Bedrock planner stricter and more transparent.
- Add richer multimodal evidence grounding in the UI.
- Deepen the Nova 2 Sonic voice path for live incident intake.
- Connect a stronger Nova Act workflow path for browser-based operational actions.
- Improve replay exports and operational reporting.
- Expand the pack model into more command-center domains.
The long-term vision is for Nova A.R.C. to become a universal agentic runtime for operations: a configurable system where teams can load a mission pack, define a prime directive, connect the right tools, and run a trustworthy command center on top of Amazon Nova.
Prime Directive in. Mission pack loaded. Incident contained.
Log in or sign up for Devpost to join the conversation.