Deployment models

The same signed application and schema support five profiles. Legal and sector configuration—not a marketing label—determines acceptable location and access.

Profile comparison

Profile	Control plane	Data plane agent	Keys	Upgrade
multi-tenant SaaS	OpenDPDP India region, shared service/isolated tenant data	customer VPC/on-prem preferred	managed KMS, optional tenant key	managed train
dedicated managed	isolated customer stack	customer boundary	dedicated/tenant key	managed window
customer VPC	customer cloud account	same account/on-prem	customer KMS	signed pull/GitOps
on-prem Kubernetes	customer data centre	local	customer HSM/KMS	offline-capable bundle
air-gapped	isolated cluster	local	customer HSM	signed media, delayed legal feed

Docker Compose is evaluation only and uses synthetic data. It is not a production HA claim.

Tenant isolation

Multi-tenant SaaS uses tenant ID in every resource/key/path/message, PostgreSQL RLS, per-tenant envelope keys where justified, scoped object prefixes, separate cache namespaces and queue attributes. CI runs cross-tenant negative tests for API, direct object access, search, job, export, support and backup restore.

Dedicated/VPC/on-prem are not exempt from application tenant checks; this prevents future consolidation and operator error.

Baseline topology

flowchart TB
  LB[Ingress/WAF] --> APP[Stateless app replicas]
  APP --> PG[(HA PostgreSQL)]
  APP --> OBJ[(Object evidence store)]
  APP --> Q[Durable job queue]
  Q --> W[Worker replicas]
  APP --> K[KMS/HSM and secrets]
  APP --> O[Privacy-safe observability]
  W --> E[Outbound mTLS to agents/providers]

No service requires inbound access to customer databases. Agents poll or accept explicitly allow-listed mTLS calls.

SLO tiers

Tier	Availability target	RPO	RTO	Use
evaluation	best effort	24 h	24 h	synthetic
standard	99.9% monthly	15 min	4 h	privacy operations
critical	99.95% monthly	5 min	1 h	public consent/incident workflows

Targets exclude agreed maintenance and customer-side dependency failure, reported separately. Statutory deadline continuity uses offline packs and manual fallback; SLO is not legal safe harbour.

Capacity assumptions

Pilot reference: 10 legal entities, 500 admin users, 10 million Principal references, 100 million receipts/year, 100,000 cases/year, 2,000 systems/vendors, burst 500 consent writes/second. Partition receipts/audit by time and tenant hash; object content stays outside hot relational rows. Load tests validate p95 consent write below 300 ms excluding external propagation and console reads below one second for indexed queues.

Backup and recovery

Encrypted point-in-time PostgreSQL recovery, versioned/immutable evidence objects, configuration exports and KMS recovery procedure. Quarterly restore into isolated environment verifies tenant scope, manifest, connector secrets references and deletion tombstone replay. Keys are never stored inside the backup they protect without a separated recovery control.

Upgrade and rollback

Signed images/SBOM/provenance; preflight compatibility; expand/migrate/contract schema changes; database backup and migration journal; canary/blue-green where supported; application rollback only when schema compatibility permits. Legal configuration activates separately and can be rolled back prospectively with a reviewer decision—historic evidence is immutable.

Air gap

Bundle images, charts, schemas, source/control configuration, SBOM, signatures and revocation list. Customer verifies offline. Regulatory updates enter through two-person media handling; stale legal content is prominently shown. No hidden licence callback or telemetry.

Exit

Export configuration, sources, receipts, cases, audit and evidence manifests in documented open formats; cut connectors; revoke keys/service accounts; delete workload and backups per schedule; list holds/exceptions. Terraform/Helm state belongs to the customer in VPC/on-prem profiles.