Architecture

DRC is an evidence system with one explicit authority per operating mode.

Local mode

application traffic
  → capture
  → StoragePlaneAdapter
  → WAL
  → signed segments
  → verified reconstruction
  → deterministic replay

The local adapter owns capture, search, replay, and deletion for the workspace. Its bounded cache is a hot-read optimization, not a second source of truth. Durable local segments require a managed signing key.

Hosted mode

authenticated capture
  → PostgreSQL receipt
  → bounded Redis promotion state
  → immutable artifact store
  → PostgreSQL artifact link
  → hosted replay and workbench

PostgreSQL owns tenant, project, receipt, lifecycle, and workflow state. Redis accelerates promotion and coordination. Object storage owns immutable artifact bytes only after digest, size, and link verification succeed.

Recovery mode

PostgreSQL receipt + immutable artifact + WAL reconciliation
  → verified manifest
  → isolated restore
  → known workload replay
  → measured recovery result

A created backup is not evidence of recovery. Restore verification must replay a known workload and record the measured RPO/RTO.

Evidence boundaries

Every hosted read checks tenant identity and resource ownership. Portable evidence bundles contain provenance, digests, and signer metadata so an auditor can verify them without a live DRC service. Unverified metadata is labeled as such.

Why the boundaries matter

DRC can run beside any application because capture is port/runtime-oriented. Language metadata may be attached to an execution when available, but it is not a required part of the core model. OpenTelemetry provides standard trace correlation without replacing execution evidence.