JetGraph is optimized for the decision path

Traditional architecture

Event
  ↓
Database
  ↓
Aggregation
  ↓
Feature store
  ↓
Risk engine
  ↓
Decision

Each hop adds tail latency, consistency windows, and glue. Velocity is often a rollup job. Novelty is a cache or a SQL anti-join. Neighbor risk is a batch graph job that is already stale at authorize time.

JetGraph architecture

Event
  ↓
JetGraph
  ├── velocity
  ├── novelty
  ├── relationship context
  ├── neighbor risk
  └── graph signals
  ↓
Decision
  ↓
Record event + optional flag / propagate

The engine is the feature computer for graph signals. Your model or rules still own the score. JetGraph does not replace a payment processor, a warehouse, or a general-purpose graph database used for deep investigation.

Query first. Enrich. Then insert.

1. Query historical state — velocity, neighbors, node context, novelty, window aggregates. The graph reflects committed history only.
2. Enrich and decide — your weights, rules, or model. JetGraph supplies primitives.
3. Insert and propagate — write the event even when declined. Flag when thresholds breach; neighbors pick up exposure automatically.

This pattern is documented in the Rust client and risk scoring pages.

When JetGraph is the better tool

• Authorize-time or login-time decisions that need relationship + velocity together
• Fraud rings and shared-device / shared-IP patterns at one or two hops
• You can fit the hot graph in memory on one machine (with snapshot + optional standby)
• You already have (or will keep) an upstream system of record

When it is not

• You need full Neo4j Cypher, GDS algorithms, or multi-hop investigative notebooks as the system of record
• The graph cannot fit in memory and must be a distributed analytical database
• Primary need is ad-hoc BI over a large persistent graph
• You only need a few Redis counters and no relationships

Honest comparisons: vs Neo4j, vs Redis, vs PostgreSQL, vs feature stores.