NEXUS: AI Supply Chain Crisis Commander

AI incident commander that detects supply-chain disruptions, finds affected shipments, simulates recovery options, challenges recommendations, and delivers evidence-backed action plans.

Comment

Inspiration

Supply chains rarely fail because teams have no data. They fail because critical information is scattered across shipment systems, weather feeds, news, transportation networks, and operational dashboards—and humans have very little time to connect those signals before a disruption becomes a delay.

That problem inspired NEXUS: AI Supply Chain Crisis Commander.

We wanted to explore a bigger question: instead of building another chatbot that simply explains what already happened, could we build an AI system that behaves more like an incident commander?

Our goal was to create an agentic decision-support system that could detect a disruption, understand which shipments may be affected, generate recovery strategies, simulate those strategies, challenge its own recommendation with external evidence, and present a transparent action plan for human approval.

NEXUS is built around one principle:

AI should help operational teams reason faster, but deterministic calculations, external evidence, policy guardrails, and humans should govern action.

What it does

NEXUS acts as an AI-powered decision-support system for supply-chain disruptions.

The current demonstration uses a synthetic global transportation network containing:

  • 1,200 active shipments
  • 1 active disruption
  • 234 exposed shipments
  • 18 critical exposed shipments

The demo models a severe-weather disruption affecting Memphis across air and road transportation.

When a disruption is detected, NEXUS executes a structured crisis-response workflow:

  1. Detects the disruption signal
  2. Identifies affected shipments
  3. Analyzes operational impact
  4. Generates multiple recovery strategies
  5. Simulates delay, cost, risk, and SLA trade-offs
  6. Challenges the leading strategy with external evidence
  7. Synthesizes an evidence-backed decision
  8. Applies a deterministic policy gate
  9. Requires human approval before action
  10. Provides Decision Replay and What-If analysis

The overall workflow is:

Detect → Impact → Analyze → Plan → Simulate → Challenge → Decide → Human Gate → Replay + What-If

Detecting shipment exposure

NEXUS does not ask the language model to decide whether a shipment is affected.

A deterministic Python impact engine compares shipment routes, geographic coordinates, transportation modes, shipment status, incident radius, and incident severity.

For the synthetic Memphis scenario, the engine identifies:

  • 234 exposed shipments
  • 18 critical exposed shipments

The system also assigns an operational-risk score based on factors such as:

  • incident severity,
  • shipment priority,
  • proximity to the disruption,
  • shipment status,
  • affected transportation mode.

Shipments that are more critical and closer to the disruption receive higher operational priority.

Importantly, these calculations happen before any LLM reasoning occurs.

AI incident analysis

Once the deterministic impact calculation is complete, structured incident information is sent to NVIDIA Nemotron through Nebius Token Factory.

The model used is:

nvidia/nemotron-3-super-120b-a12b

Nemotron acts as an Incident Analysis Agent and produces:

  • an executive summary,
  • operational assessment,
  • priority triage actions,
  • watch items,
  • assumptions,
  • model confidence.

Nemotron does not calculate shipment exposure, cost, delay, risk, or SLA outcomes.

Its responsibility is reasoning and interpretation, while deterministic Python remains the numerical source of truth.

Recovery planning

The Recovery Planner generates multiple bounded recovery strategies rather than returning a single immediate recommendation.

The current system evaluates three major strategy types:

Hold and Monitor

Maintain current transportation paths while continuously monitoring the disruption.

Full Network Diversion

Reroute all exposed shipments through an alternate transportation hub.

Priority Protection

Reroute only Critical and High-priority shipments while standard-priority shipments remain on their existing routes.

The model may reason about which alternate hub should be considered, but it is explicitly prevented from inventing numerical values for:

  • delay,
  • cost,
  • residual risk,
  • SLA performance,
  • capacity,
  • congestion.

Those values are calculated by the deterministic simulation engine.

Deterministic simulation

Each recovery strategy is evaluated using Python.

The simulator calculates:

  • average recovery delay,
  • incremental transportation cost,
  • residual disruption risk,
  • SLA exposure,
  • number of shipments rerouted,
  • percentage of critical shipments protected.

The calculations use the synthetic shipment network, route geometry, incident severity, incident duration, shipment priorities, and fixed simulation coefficients.

These values are comparative hackathon estimates, not carrier quotations or live capacity commitments.

Strategy scoring

The simulator compares each recovery strategy across four dimensions:

  • Delay
  • Cost
  • Residual risk
  • SLA exposure

The default business priorities are:

  • Delay: 35%
  • Cost: 20%
  • Residual risk: 30%
  • SLA exposure: 15%

The strategy with the lowest weighted score becomes the Simulation Leader.

That distinction is intentional.

The Simulation Leader is not automatically the final recommendation.

It must still survive the evidence challenge.

Challenge — Making the AI question its own recommendation

One of the most important features of NEXUS is that it does not automatically accept the simulation leader.

Instead, a separate Critic Agent attempts to identify reasons that the proposed strategy could fail.

Before the Critic evaluates the plan, Tavily retrieves current public information related to important assumptions behind the proposed alternate hub.

For example, NEXUS can search for:

  • airport operating status,
  • weather conditions,
  • transportation interruptions,
  • road closures,
  • severe-weather advisories,
  • publicly reported operational constraints.

Each retrieved source receives a structured evidence identifier such as:

E1, E2, E3, ...

The Critic Agent can reference only evidence IDs that were actually retrieved.

Each important assumption is classified as:

  • SUPPORTED
  • UNVERIFIED
  • CONTRADICTED

This distinction is important.

For example, public evidence may confirm that Atlanta airport is operating.

However, that does not prove that Atlanta can absorb 234 additional diverted shipments.

Operating status and spare capacity are different questions.

Therefore, the capacity assumption remains UNVERIFIED unless the supplied evidence explicitly establishes it.

Likewise, lack of evidence is not automatically treated as contradiction.

This prevents the AI from converting uncertainty into false confidence.

Evidence-backed decision

The final Decision Agent receives:

  • disruption information,
  • shipment-impact results,
  • deterministic simulation outcomes,
  • recovery strategies,
  • Tavily evidence,
  • Critic findings,
  • unresolved assumptions.

Nemotron synthesizes that information into a final decision recommendation.

However, the language model is still not the execution authority.

After the AI responds, NEXUS applies a separate deterministic policy gate.

The system can return:

READY FOR HUMAN APPROVAL

or:

HOLD FOR HUMAN VALIDATION

The policy gate can override the model when:

  • a material assumption is contradicted,
  • important operational assumptions remain unresolved,
  • evidence is insufficient,
  • evidence is stale,
  • the Critic identifies a blocking issue.

This means an AI-generated recommendation alone is never enough to authorize action.

Human Approval

Even when a strategy passes the policy gate, NEXUS does not automatically execute it.

The human operator remains the final authority.

The current demonstration often ends with:

HOLD FOR HUMAN VALIDATION

because live public evidence cannot reliably establish exact spare airport capacity, available handling slots, carrier willingness, or other operational commitments.

For NEXUS, that is not a failed result.

It demonstrates that the system can recognize when available evidence is insufficient and stop instead of forcing a recommendation.

Decision Replay

NEXUS records the complete decision workflow as a Decision Replay:

  1. DETECT
  2. IMPACT
  3. ANALYZE
  4. PLAN
  5. CHALLENGE
  6. DECIDE

Each stage shows:

  • what happened,
  • important facts,
  • the responsible system,
  • runtime information,
  • model usage where appropriate.

For example:

IMPACT
System of record: Python deterministic impact engine

ANALYZE
System of record: NVIDIA Nemotron through Nebius Token Factory

CHALLENGE
System of record: Tavily + Nemotron Critic

DECIDE
System of record: Nemotron Decision Agent + deterministic policy gate + human gate

Decision Replay therefore provides process-level explainability instead of generating a post-hoc paragraph explaining the final answer.

What-If Mode

NEXUS also allows operators to change the importance of:

  • delay,
  • cost,
  • residual risk,
  • SLA protection.

The What-If Lab includes presets such as:

  • Balanced
  • Speed First
  • Cost First
  • Risk First
  • SLA Protection
  • Custom

NEXUS re-ranks the same deterministic simulation results using the updated business priorities.

For example, a strategy that performs best under a balanced objective may no longer lead when cost becomes the highest priority.

The important part is that What-If Mode makes:

  • 0 additional Nemotron calls
  • 0 additional Tavily searches

It reuses the existing Stage 4 simulation results.

If the What-If leader changes, NEXUS does not automatically promote it into the final decision workflow.

The new strategy would first need its own evidence challenge.

How we built it

NEXUS was designed as a multi-component decision system rather than a single large-language-model prompt.

The architecture deliberately separates responsibilities.

NVIDIA Nemotron + Nebius Token Factory

NVIDIA Nemotron performs four major reasoning roles:

  • Incident Analyst
  • Recovery Planner
  • Critic Agent
  • Decision Agent

Inference is provided through Nebius Token Factory.

Token Factory allowed us to use a large NVIDIA reasoning model through a hosted API without provisioning or managing GPU infrastructure ourselves.

This significantly accelerated development because we could focus on:

  • prompt engineering,
  • structured outputs,
  • agent orchestration,
  • evidence integration,
  • evaluation,
  • application logic.

Tavily

Tavily provides the external evidence-retrieval layer.

Instead of being included as a generic search feature, Tavily directly affects the decision workflow.

Its evidence can cause the Critic Agent to challenge the Simulation Leader and can ultimately cause the deterministic policy gate to stop the workflow.

Deterministic Python engines

Python handles the parts of the workflow that require repeatability and auditability:

  • shipment exposure,
  • geographic calculations,
  • shipment targeting,
  • delay simulation,
  • cost simulation,
  • residual-risk calculation,
  • SLA exposure,
  • strategy scoring,
  • What-If re-ranking,
  • policy-gate enforcement.

The responsibility split is intentionally simple:

AI → reasoning and synthesis

Python → calculations

Tavily → external evidence

Critic → assumption testing

Policy Gate → hard constraints

Human → final authority

Streamlit

The NEXUS command center was built using Streamlit, Plotly, Pandas, and custom CSS.

The interface includes:

  • global transportation-network visualization,
  • incident intelligence,
  • shipment exposure metrics,
  • affected shipment tables,
  • Nemotron operational analysis,
  • recovery-strategy cards,
  • deterministic simulation metrics,
  • Critic review,
  • Tavily evidence inspection,
  • policy-gate results,
  • Decision Replay,
  • What-If analysis,
  • runtime telemetry,
  • exportable decision packets.

The application is deployed publicly using Streamlit Community Cloud.

FastAPI

FastAPI was used during development to expose shipment, incident, and impact-analysis endpoints.

For local development:

Streamlit → FastAPI → NEXUS runtime

For Streamlit Community Cloud:

Streamlit → Embedded deterministic NEXUS runtime

This allowed us to preserve the API architecture for development while deploying the complete hackathon demonstration as a single hosted Streamlit application.

Challenges we ran into

One of the biggest challenges was preventing NEXUS from becoming just another LLM wrapper.

It is easy to ask a model:

What should I do about this disruption?

It is much harder to build a system where the answer depends on shipment data, external evidence, deterministic calculations, competing alternatives, explicit criticism, and policy constraints.

Separating reasoning from calculation

Language models are valuable for contextual reasoning, strategy generation, critique, and synthesis.

They are less appropriate as the source of truth for numerical operational metrics.

We therefore established a clear boundary:

Nemotron reasons about the problem.

Python calculates the operational outcomes.

That separation became one of the core architectural decisions in NEXUS.

Keeping AI language aligned with deterministic execution

During development, the Priority Protection strategy exposed an important consistency issue.

The deterministic simulator correctly targeted:

  • 18 Critical shipments
  • 58 High-priority shipments
  • 76 total targeted shipments

However, an earlier model-generated description referred only to the 18 critical shipments.

Instead of manually fixing the text, we fixed the architecture.

Python became the source of truth for:

  • target scope,
  • shipment counts,
  • priority breakdown,
  • rerouted population.

The UI now derives those values from deterministic results rather than trusting free-text model output.

Handling incomplete evidence

Public information can often verify:

  • operating conditions,
  • delays,
  • weather alerts,
  • closures,
  • public advisories.

But it may not verify:

  • exact spare cargo capacity,
  • carrier willingness,
  • available handling slots,
  • contract eligibility,
  • ability to absorb a specific diversion volume.

That led to two important principles:

Unverified does not mean false.

No evidence does not mean contradicted.

Making uncertainty visible became more valuable than forcing certainty.

Preventing the model from bypassing guardrails

Even after adding the Critic Agent, we needed to ensure that the final AI model could not simply ignore the critique and approve a risky strategy.

That led to the deterministic Stage 6 policy gate.

The final workflow effectively requires three things:

  1. AI recommendation
  2. Policy clearance
  3. Human approval

If any required condition fails, NEXUS stops the workflow.

Deploying a multi-component system

During development, Streamlit communicated with a local FastAPI service.

Streamlit Community Cloud does not automatically launch a second localhost server, so the deployment architecture needed to change.

NEXUS now supports both:

Local development: Streamlit → FastAPI → NEXUS

Cloud deployment: Streamlit → Embedded NEXUS runtime

This preserved the local API architecture while allowing the entire demonstration to run as one deployed Streamlit application.

Accomplishments that we're proud of

We are proud that NEXUS goes beyond conversational AI and treats the language model as one component inside a larger operational decision system.

Some of the capabilities we built include:

  • a multi-stage disruption-response workflow,
  • deterministic geospatial shipment-impact analysis,
  • NVIDIA Nemotron inference through Nebius Token Factory,
  • bounded AI recovery planning,
  • deterministic delay/cost/risk/SLA simulation,
  • Tavily-powered public evidence retrieval,
  • an independent Critic Agent,
  • evidence-source validation,
  • deterministic policy enforcement,
  • human approval,
  • Decision Replay,
  • interactive What-If analysis,
  • runtime telemetry,
  • evidence freshness checks,
  • exportable decision packets,
  • public Streamlit deployment.

The capability we are most proud of is NEXUS's ability to challenge itself.

Instead of trying to make the AI appear more confident, the system actively looks for evidence that its preferred strategy may be unsafe or unsupported.

A successful NEXUS workflow can therefore finish with:

HOLD FOR HUMAN VALIDATION

rather than forcing an answer.

What we learned

Building NEXUS reinforced that the quality of an agentic AI system depends on more than the size of the model.

Different components should own different types of truth:

  • LLM: reasoning and synthesis
  • Deterministic software: numerical calculations
  • Search: external evidence
  • Critic: assumption testing
  • Policy engine: constraint enforcement
  • Human: final authority

We also learned that tool use is most valuable when it can actually change the system's decision.

Tavily is not included simply to display search results. Its evidence can cause the Critic Agent to challenge the leading strategy.

Similarly, explainability is more useful when it exposes the actual decision process rather than generating a post-hoc explanation.

Decision Replay shows:

What happened → What was affected → What options were considered → How they performed → What the AI proposed → What challenged the proposal → Why the workflow proceeded or stopped

What's next for NEXUS: AI Supply Chain Crisis Commander

The current implementation is a synthetic hackathon prototype, but the same architecture could be extended into real operational environments.

Future versions could integrate with:

  • transportation-management systems,
  • warehouse-management systems,
  • real-time shipment-visibility platforms,
  • carrier APIs,
  • airport and port operations feeds,
  • weather APIs,
  • road and transportation alerts,
  • customer SLA systems,
  • capacity-management platforms.

Additional capabilities could include:

Multi-incident reasoning

Simultaneously evaluate weather, congestion, infrastructure failures, strikes, port events, and geopolitical disruptions.

Network optimization

Combine AI-generated strategies with operations-research solvers for large-scale routing and allocation.

Persistent incident memory

Store previous incidents, proposed strategies, human decisions, and actual outcomes so future recommendations can use historical recovery performance.

Predictive disruption detection

Move from reacting to disruptions toward predicting emerging risk before shipment exposure occurs.

Confidence calibration

Compare model confidence with historical accuracy and evidence quality.

Enterprise policy configuration

Allow companies to configure:

  • financial approval thresholds,
  • acceptable SLA risk,
  • escalation rules,
  • evidence requirements,
  • role-based human approval.

Production observability

Add persistent logs, model evaluations, evidence provenance, tracing, alerting, and complete decision auditing.

Ultimately, our vision for NEXUS is larger than supply-chain monitoring.

We see it as a blueprint for operational AI systems that do not merely answer questions, but:

  • gather evidence,
  • calculate measurable outcomes,
  • evaluate alternatives,
  • challenge their own assumptions,
  • represent uncertainty,
  • enforce policy,
  • and preserve human authority.

NEXUS does not just recommend. It simulates, challenges, verifies, explains, and knows when to stop for a human.

Built With

Share this project:

Updates

Submission history