rushdb
Sign InGet API Key

Blueprint: supply chain analytics

See dependency chains before a disruption forces you to.

A single supplier delay can cascade through products, warehouses, and orders in ways that are hard to see from any one system, especially when supplier, shipment, and inventory data each live in a different logistics tool. This blueprint connects suppliers, shipments, products, and warehouses as a graph, so dependency mapping and disruption-impact questions run as traversals against live status instead of a manual cross-system investigation.

Supply chain graph analytics is a RushDB blueprint that connects SUPPLIER, SHIPMENT, PRODUCT, and WAREHOUSE records as one graph, so dependency mapping and disruption-impact queries traverse the network directly instead of requiring manual cross-referencing between separate logistics systems.

Start freeView docs

Dependency chains are invisible until a disruption forces a manual investigation.

Which products depend on a given supplier, which warehouses are affected by a delayed shipment, and how deep a disruption cascades downstream are all graph questions. Without connected data, answering them means manually cross-referencing multiple logistics systems while a disruption is already active, instead of running a query against a dependency graph that was already there.

Before

  • Supplier, shipment, and product data live in separate logistics systems
  • Dependency mapping happens manually during an active disruption
  • Bottleneck identification requires a specialist to trace relationships by hand
  • Risk assessment is a periodic manual review, not a standing query

With RushDB

  • Suppliers, shipments, products, and warehouses are connected Records
  • Dependency and disruption-impact queries traverse the graph directly
  • Bottleneck and single-point-of-failure analysis runs as a standing query
  • New suppliers or routes extend the same graph without a migration

Graph intelligence on ingest

Incoming data becomes queryable graph context.

A SUPPLIER record with nested SHIPMENT and PRODUCT arrays lands connected on write, so an impact trace never depends on a batch job reconciling logistics feeds after the fact. RushDB infers region, status, and ETA types from the payload, links each SHIPMENT and PRODUCT to its SUPPLIER automatically, and can suggest WAREHOUSE-level relationships once shipment and inventory data from separate systems accumulates.

01

Normalize logistics data as it arrives

Import SUPPLIER records with nested SHIPMENT and PRODUCT data. RushDB infers region, status, and ETA types without a schema migration.

02

Auto-link the supply network

Nested SHIPMENT and PRODUCT entries in a supplier payload become Records connected to their SUPPLIER automatically, preserving the dependency structure already in the feed.

03

Enrich across warehouse and ERP sources

When WAREHOUSE or inventory data arrives from a separate ERP export, suggested-relationship analysis can propose how it joins to the existing supplier and product graph.

Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.

Review suggested relationship patterns

Data model

One flexible graph for the workflow.

Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.

Schema sketch
Supplier dependency payload

One supplier write can carry its shipments and the products it supplies, so downstream impact is traceable immediately.

{
  "supplierId": "sup-114",
  "region": "southeast-asia",
  "SHIPMENT": [{ "shipmentId": "ship-902", "status": "delayed", "etaDays": 12 }],
  "PRODUCT": [{ "sku": "sku-widget-07" }]
}

Working example

Trace disruption impact from one delayed shipment.

Once suppliers, shipments, and products are connected, a delay at one supplier traces directly to the products and warehouses it affects.

Input
SUPPLIER sup-114
  region: "southeast-asia"
  SHIPMENT: [{ shipmentId: "ship-902", status: "delayed", etaDays: 12 }]
  PRODUCT: [{ sku: "sku-widget-07" }]
Query
{
  "labels": ["SUPPLIER"],
  "where": { "supplierId": "sup-114" },
  "relatedTo": { "label": "PRODUCT", "via": "SUPPLIES" }
}
Result
{
  "supplier": "sup-114",
  "status": "delayed",
  "affected_products": ["sku-widget-07"],
  "affected_warehouses": ["wh-central-02"]
}

TypeScript SDK

Traverse from a delayed supplier to its downstream impact.

The same graph supports both real-time disruption tracing and periodic dependency-risk review.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

schema = db.ai.get_schema_markdown({'labels': ['SUPPLIER', 'SHIPMENT', 'PRODUCT', 'WAREHOUSE']}).data

impact = db.records.find({
    'labels': ['SUPPLIER'],
    'where': {'supplierId': 'sup-114', 'SHIPMENT': {'status': 'delayed'}},
})

Implementation blueprint

Build the supply chain dependency graph.

Use this sequence to connect suppliers, shipments, products, and warehouses for dependency and disruption analysis.

  1. 01Import SUPPLIER records with region and reliability fields
  2. 02Import SHIPMENT records linked to their supplier and status
  3. 03Link PRODUCT records to the suppliers and warehouses they depend on
  4. 04Update shipment status as logistics events occur
  5. 05Query dependency and disruption-impact questions as graph traversals

Build path

  • Keep supplier, shipment, product, and warehouse relationships explicit, not siloed per logistics system.
  • Update shipment status in place so disruption queries reflect current state.
  • Use exact filters for region, status, and product category before any broader traversal.
  • Treat disruption-impact output as investigation support, not an automated rerouting decision.

Relevant docs

Read the exact primitives behind this pattern.

These links point to the RushDB docs pages that map directly to this blueprint: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.

Relationships

Connect suppliers, shipments, products, and warehouses into one dependency graph.

Open docs

Search introduction

Trace disruption impact from a supplier or shipment to the products and warehouses it affects.

Open docs

Import JSON data

Push supplier, shipment, and product data as nested records and let RushDB build the graph.

Open docs

How it works

Build the smallest useful workflow first.

01

Connect the supply network

Import suppliers, shipments, products, and warehouses as connected Records.

02

Trace disruption impact

Query from a delayed or at-risk supplier to the products and warehouses downstream of it.

03

Review dependency risk on a standing basis

Run bottleneck and single-point-of-failure queries periodically instead of only during an active disruption.

Know where it fits.

Query risk before it becomes a disruption

Dependency mapping runs as a standing query, not only as a reactive investigation after a delay is already reported.

This is investigation support

Impact traces help a logistics team prioritize response. Rerouting, supplier changes, and mitigation remain human decisions.

Questions developers ask.

Next step

Start with one focused workflow.

Start free

Related use cases

Explore all use cases

E-commerce graph analytics

Analyze purchasing behavior, product relationships, and cross-sell opportunities from one connected graph.

Explore e-commerce analytics

Customer 360 graph analytics

Connect users, orders, subscriptions, support interactions, and events into one queryable customer graph.

Explore customer 360 analytics

Vulnerability and asset risk graph

Connect assets, CVEs, and patch status so security teams can query which critical vulnerabilities touch internet-facing systems.

Explore the risk graph