Platform architecture

How ARA fits into your stack,
and how one entity stays known.

Two views of the same system. First, where ARA sits relative to everything already making decisions in your stack. Then, what that means for a single entity over time: one write per decision, and every downstream question, audit, blast radius, drift, becomes a single query.

Platform architecture

Every decision, from every system,
on one persistent plane.

Decisions happen everywhere
Risk
Fraud
Credit
Support
Marketing
Collections
Inputs to decisions
Entity ID
Features
Events
Context
Model info
Metadata
ARA
Preserves the decision state
  • Immutable entity state
  • Complete history of inputs and outputs
  • High throughput, low latency
  • Queryable and replayable
Integration pathways from ARA
Pathway 1 · Serving path on critical path
Train / ingest
→
ARA serves features
→
Decision
ARA is the serving engine, not a downstream log: it answers the feature request and captures the decision in the same call.
Pathway 2 · Ledger not on critical path
Decision made
→
API call to ARA
→
Recorded in ARA
ARA records independently, after the fact, for audit and observability.
Incident MTTR
Blast radius
Drift alerts
Anomaly detection
Data quality
Access & governance
One entity, one history

One write.
Everything else becomes a query.

Decisions happen everywhere
Risk engine
Fraud model
Credit engine
Support agent
Collections
ARA captures at inference
  • Exact feature state: what the model actually saw
  • Model version
  • Timestamp
  • Output
  • Decision ID
entity #8734213
One entity.
Persistent decision state.
entity #8734213, known across every decision
  • Jan 14 · 2:47pmLoan pre-approval
  • Jan 28 · 11:03amLimit increase
  • Feb 2 · 9:14amFraud flag
  • Feb 2 · 9:31amAccount freeze
  • Feb 9 · 2:05pmDispute overturned
Persistent decision state · queryable in <2μs
Audit answerone query
Blast radiusone query
Drift alertone query
Agent memoryone query
Download Community Edition Read the docs Talk to sales →