Meridian Operations

Business Problem

Supply chain operations teams detect disruption late because visibility is fragmented across as many as 15 disconnected systems. By the time a disruption is confirmed, the window to act cheaply has usually closed, and the investigation that follows consumes days of analyst time that should have gone into prevention.

Customer / User Context

Built around two personas: a Supply Chain Operations Director who needs early risk visibility and cross-team coordination without another status meeting, and a Supply Chain Analyst who needs to go from “something broke” to root cause without manually reconciling a dozen systems. Both are blocked less by a lack of data and more by data that exists but isn't connected.

Approach

Rather than building another dashboard that reports isolated metrics, Meridian Operations is designed around a connected operational ontology: suppliers provide products that move through ports; disruptions attach to those flows; disruptions trigger human decisions; decisions affect customer orders. Because every entity is linked, a single disruption can be traced forward to its downstream business impact instead of sitting in a table as an isolated incident.

Architecture

Business workflow (disruption occurs → detected → investigated → decision made → response coordinated) sits on top of a Postgres data model, via Supabase, that encodes the supplier → product → port → disruption → decision → order relationships as first-class links rather than joined-after-the-fact reports. The frontend reads this connected model directly, so the impact-trace view is a graph traversal, not a custom report someone has to build.

Technology Stack

Business Outcome

The platform's demo scenarios illustrate the shift a connected model makes possible: detection time compressed from roughly 14 days to about 2 hours, investigation effort from roughly 40 hours to about 5 hours, with an estimated $2.8M in disruption cost avoided in the modeled scenario.

These are illustrative demo-scenario figures published on the live platform, not audited metrics from a production customer deployment, presented here exactly as the platform frames them.

Lessons Learned

The hardest part of an “operational decision platform” isn't the dashboard, it's deciding what counts as one entity versus a relationship between two entities, because that decision determines whether impact tracing is a query or a project. Getting the ontology right up front paid for itself every time a new workflow needed to be added without a schema rewrite.

Deployment

Deployed on Vercel, connected to a Supabase Postgres instance. Continuous deployment from the main branch of the meridian-ops repository.