Skip to main content

Architecture Overview

Pavri has three product surfaces:

  • SDKs and plugins inside customer agent runtimes
  • backend services for ingest, storage, policy, alerting, and detection
  • an operator-facing dashboard

Current Backend Slice​

The implemented Sprint 2 backend path looks like this:

  1. the gateway accepts SDK-facing gRPC traffic
  2. the gateway forwards registration and telemetry to ingest
  3. ingest validates telemetry and publishes it into NATS JetStream
  4. store consumes telemetry from JetStream and persists event history into ClickHouse
  5. policy serves bootstrap and watch responses from PostgreSQL-backed metadata

PostgreSQL owns metadata and policy state. ClickHouse owns immutable event analytics. JetStream is the transport layer between services rather than the source of truth.

Current SDK Slice​

The Python SDK currently ships:

  • secure() runtime assembly
  • deterministic fingerprinting and registration scaffolding
  • local policy bootstrap and cache refresh flow
  • startup telemetry scaffolding
  • adapter selection for generic, langgraph, and crewai

The live Python exporter into the Go backend is still deferred, so the repo-local quickstart verifies local SDK/runtime behavior while the Go service tests verify the backend pipeline.

Deferred Product Surfaces​

  • dashboard inventory and session exploration are deferred to Sprint 3
  • policy CRUD and governance UI are deferred to Sprint 4
  • threat detection workflows and response actions are deferred to Sprint 5

The deeper design rationale still lives in the internal planning docs, but the public documentation now tracks the implemented runtime and backend slice directly.