Deployment

Choose the operating boundary before the infrastructure.

Clarivy supports SaaS, customer-controlled cloud and on-premises models. Identity, data location, key ownership, AI providers and operational responsibility are agreed first.

Deployment models

ModelBest fitCustomer controlClarivy responsibility
Clarivy SaaSFast design-partner pilot or shared managed service.Tenant policy, users, approved connectors and data requirements.Application operations, shared platform controls and support.
Private cloudRegulated customer requiring a dedicated environment.Subscription, network, identity, keys and regional policy.Product release, configuration, integration and agreed operations.
On-premisesCustomer requiring local infrastructure and restricted egress.Compute, network, storage, identity, backup and runtime access.Licensed software, deployment package, documentation and support boundary.

Azure reference architecture

The recommended production path uses managed services rather than running every dependency on one host. Container Apps scale the web, API and workers independently; PostgreSQL remains authoritative; Blob Storage holds evidence artifacts; Service Bus carries retryable work.

Production deployments keep tenant identity, policy, case stores and audit lineage inside Clarivy while approved connectors stay connectivity-only.

Production request path

  1. 1

    Controlled edge

    Staff, merchants and partner systems enter through managed TLS, web-application firewall and API controls.

  2. 2

    Identity and authority

    Enterprise identity proves who the caller is; Clarivy computes tenant, role, workflow and segregation-of-duties permissions.

  3. 3

    Short case transaction

    The API records authoritative state and sends expensive or retryable work to a queue.

  4. 4

    Independent workers

    Evidence, document and communication workers scale from queue depth with bounded retries and idempotency.

  5. 5

    Controlled intelligence

    OCR and model providers return provisional structured output through the existing Clarivy harness.

  6. 6

    Observable outcome

    Metrics, traces, audit lineage and cost-per-case remain available without logging sensitive document or prompt content.

Scaling stages

StageRuntime patternReliability and cost posture
Design-partner pilotOne managed environment, one warm API, workers scale to zero, PostgreSQL with vector extension.Backup-based recovery and strict budget caps.
Controlled productionTwo warm API replicas, queue-scaled workers, private data services and managed edge protection.Zone-redundant database, formal alerts and restore exercises.
Regulated enterpriseDedicated or customer-hosted environment with customer-specific network and key controls.Contracted recovery, isolation, retention and operational evidence.

Acceptance gates

  • Every customer-owned query is tenant constrained.
  • Client input cannot choose a storage path or audit identity.
  • Policy versions, hashes and model runs remain reconstructable.
  • Duplicate events do not create duplicate effects.
  • AI and OCR outages degrade safely to manual review.
  • Restore objectives are agreed and proven.
  • Secrets are managed outside repositories and browser code.
  • Residency, retention and provider boundaries are contractually approved.

Architecture guidance, not a certification

The final topology depends on the customer’s regulator, privacy regime, approved model providers, data-residency requirement, recovery objective and security architecture. A deployment is not production-ready until those controls are tested and contractually assigned.

Continue reading

Technical and compliance glossary

Review the terms used across the production architecture and control model.