Think of This as "Live Google Maps for Cargo Ships"
When you drive to work and an accident blocks the highway, Google Maps reads live traffic and reroutes you in under a second. In global ocean shipping, that doesn't happen. When a dockworker strike shuts down the Port of Los Angeles or a drought restricts the Panama Canal, it typically takes 24 to 48 hours for human analysts to read the news, estimate the financial damage, type new numbers into spreadsheets, and re-run routing software.
Breaking news hits → Analysts read articles the next morning → Teams debate how much the delay costs → Someone manually edits an Excel table → Solver runs. Meanwhile, cargo ships sit stuck in traffic burning fuel and paying thousands of dollars in late fees.
Live maritime news streams in → AI (System 1) reads the headline and converts it into exact dollar & delay penalties → The cost table updates automatically → Quantum & Classical solvers (System 2) immediately switch to the best bypass route.
4 Terms You See on the Dashboard
Our Flight Deck tracks goods moving from factories in Southeast Asia (Thailand & Singapore) across the Pacific Ocean to a central US rail hub in Chicago via 3 US entry ports (Los Angeles, Seattle, or Savannah via the Panama Canal).
A complete highway from factory to warehouse—for example, SIN-SEA-CHI means shipping by sea from Singapore to Seattle, then by freight train to Chicago. We have 6 corridors in total.
The standard 40-foot metal cargo box you see on ships and trains. When the table says $3,680 / FEU, that is the price to ship one 40-foot box along that corridor.
Dwell time is how many days a container sits waiting at a congested port. Demurrage is the late fee ports charge per day ($350/day in our model) when containers get stuck.
Ships waiting in port queues or taking long detours burn extra bunker fuel, emitting \(\text{CO}_2\). Companies price carbon at $80 per metric ton so the solver balances money saved against pollution avoided.
Why You Can't Saw a Ship in Half (And Why Combinations Explode)
A Solver is a mathematical engine that takes your goal ("minimize cost and carbon") and your rules ("deliver the cargo to Chicago") and calculates the best decision. But in physical logistics, there is a famous catch:
Basic spreadsheet solvers use Continuous Linear Programming (LP), which allows decimals between 0.0 and 1.0. If one port has a capacity limit, Continuous LP says: "Easy! Send 0.65 of a ship to Seattle and 0.35 of a ship to Tacoma."
In reality, you cannot saw a steel cargo ship into 0.35 and 0.65 pieces!
To model the real world, we must force every decision to be a whole number: 0 (do not take this route) or 1 (take this route). This is called Mixed-Integer Linear Programming (MILP) or Binary Optimization (QUBO). You can toggle between both modes in Column 2 of the dashboard to see this difference live!
Once decisions are forced to be binary (0 or 1), the number of possible combinations doubles with every new route (\(2^N\)).
In our Flight Deck with 6 corridors, there are \(2^6 = \mathbf{64}\) possible on/off combinations—small enough to inspect every single one on screen.
But in a global supply chain with 300 corridors and vessels, there are \(2^{300}\) combinations (more than the number of atoms in the observable universe). Problems where combinations explode like this are called NP-Hard—and they are the exact reason researchers build specialized classical solvers (like PuLP CBC) and quantum optimizers (like Qiskit QAOA).
Why We Combine AI (System 1) with Math Solvers (System 2)
A common mistake in AI is asking a language model to both read the news and guess the best shipping route. Language models are great at reading text, but they guess at math. Inspired by Nobel laureate Daniel Kahneman's book Thinking, Fast and Slow, our architecture splits the work into two specialized brains:
Reads messy human news headlines (e.g., "Union walkout slows Los Angeles cranes by 4.5 days") and extracts a strict, verified scorecard: which port is hit (`USLAX`), how many days of delay (`+4.5d`), and the exact penalty (`+$1,450`).
Takes System 1's penalty and updates the affected rows in the 6-corridor table. You control two sliders: α (Financial Cost Weight) and β (Carbon Sustainability Weight) to tell the system what matters most to you right now.
Runs two real mathematical optimizers side-by-side—a Qiskit Quantum Simulator and a PuLP Classical MILP Solver—to guarantee the chosen bypass route is 100% mathematically optimal.
How to Read the Quantum Histogram in Column 3
You don't need quantum physics to understand what the bottom-right chart is doing. Here is the plain-English translation of the 4 quantum concepts on screen:
0 = Off, or 1 = On). A 6-digit label like |000010> simply lists the 6 switches in order from Route 0 to Route 5. Since the fifth digit (`q_4`) is 1 and the rest are 0, |000010> means: "Ship exclusively on Route #4 (`Singapore → Seattle → Chicago`)."
Try This in 30 Seconds on the Flight Deck
In Column 1 (Left), click any live news card (e.g., the Los Angeles dockworker stoppage or Panama Canal drought)—or type your own scenario in the text box and click Execute Parallel.ai Translation.
In Column 2 (Center), watch the affected routes turn red/amber with added dwell days and dollar penalties. Click the Continuous LP Relaxation toggle to see how fractional math tries to split a ship (`0.35` / `0.65`), then switch back to Discrete MILP.
In Column 3 (Right), watch the map snap from the congested port to the optimal green bypass arc, and hover over the green bar in the Qiskit histogram to inspect its probability and ground energy.
Core Mathematical Formulation & CLI Commands
Where \(\alpha\) is financial weight, \(\beta\) is carbon weight, \(\lambda = 12,000\) is the single-route constraint penalty, and \(x_i \in \{0, 1\}\).
Mapped into a Qiskit SparsePauliOp with 21 Pauli terms (6 longitudinal \(Z_i\) fields + 15 two-qubit \(Z_i Z_j\) couplings). Ground energy matches PuLP MILP exactly.