From event firehose to explainable business insight.

A dashboard can show a drop without explaining it.

Conversion events land in one system, incidents in another, and account or feature context somewhere else entirely. A dashboard shows conversions dropping from 184 to 97 on a given day, but nothing on the chart points to incident inc-17 on the checkout feature. Teams see the dip, then spend the next hour manually rebuilding the join between EVENT, FEATURE, and INCIDENT records before they can even start investigating.

Graph intelligence on ingest

Incoming data becomes queryable graph context.

EVENT records carrying timestamp, accountId, featureId, and value arrive continuously, alongside INCIDENT records referencing the same featureId. RushDB infers types on arrival, so timestamp becomes a queryable temporal field and value stays numeric for $sum and $timeBucket aggregation without a separate ETL step reshaping the feed.

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.

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.

{
  "eventId": "evt-2026-05-11-001",
  "type": "conversion",
  "timestamp": "2026-05-11T09:00:00Z",
  "value": 1,
  "ACCOUNT": { "accountId": "acme-01", "plan": "pro" },
  "FEATURE": { "featureId": "checkout", "surface": "web" },
  "COHORT": { "cohortId": "new-signups-q2" },
  "INCIDENT": { "incidentId": "inc-17", "summary": "Elevated checkout tickets" }
}

Working example

Click the conversion dip. Retrieve the context.

The dashboard groups conversion events by day. A drill-down can then connect the affected interval to the feature and incident records that belong in the investigation.

EVENT conversion
  timestamp: 2026-05-11T09:00:00Z
  accountId: acme-01
  featureId: checkout
  value: 1

INCIDENT inc-17
  featureId: checkout
  summary: elevated support tickets during checkout

{
  "labels": ["EVENT"],
  "where": { "featureId": "checkout" },
  "select": {
    "day": { "$timeBucket": { "field": "$record.timestamp", "unit": "day" } },
    "totalValue": { "$sum": "$record.value" },
    "events": { "$count": "$record" }
  },
  "groupBy": ["day", "$record.type"],
  "orderBy": { "day": "asc" }
}

[
  { "day": "2026-05-10", "conversions": 184 },
  { "day": "2026-05-11", "conversions": 97, "related_incident": "inc-17" }
]

TypeScript SDK

Aggregate first. Drill into context second.

The metrics path stays explicit and label-scoped. Build a small server endpoint for each approved drill-down instead of passing raw query JSON from the browser.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

daily = db.records.find({
    'labels': ['EVENT'],
    'where': {'featureId': 'checkout'},
    'select': {
        'day': {'$timeBucket': {'field': '$record.timestamp', 'unit': 'day'}},
        'totalValue': {'$sum': '$record.value'},
        'events': {'$count': '$record'},
    },
    'groupBy': ['day', '$record.type'],
    'orderBy': {'day': 'asc'},
})

Implementation blueprint

Build the connected analytics path.

Use this sequence to move from event ingest to KPI cards, cohort drill-downs, and connected operational explanations.

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.

How it works

Build the smallest useful workflow first.

Know where it fits.

Questions developers ask.