Storage

This content is for 0.1. Switch to the latest version for up-to-date documentation.

Chronicle currently stores recordings and canonical sessions on the local filesystem. Storage owns durable persistence and publication primitives; ETL owns the publication decision, publication verification, and checkpoint advancement ordering. Replay reads persisted canonical artifacts rather than WAL internals.

Public data directory

Public commands resolve the data directory in this order:

--data-dir DIR;
configured data_dir;
CHRONICLE_DATA_DIR;
platform default.

A mutating command lazily creates a private directory and rejects unsafe root or symlink forms. doctor reports the existing or prospective location without creating probe artifacts.

<data-dir>/
  .chronicle-domain.lock
  catalog.json
  recordings/<bare-recording-uuid>/
  sessions/<session-uuid>/

Within one local filesystem deployment, one normalized .chronicle-domain.lock protects name claim, capture, ETL, publication, and catalog update as one transaction. The lock is a local deployment coordination mechanism, not the architectural ownership mechanism between Recorder and ETL.

Canonical publication

Each session is published as:

sessions/<session-id>/
  manifest.json
  session.json
  payloads/<sha256>

Staging directories use 0700 and files use 0600 on Unix. The manifest is written last, and publication renames only to an absent destination. Inspect verifies artifact metadata; replay hydrates payloads and checks SHA-256.

What is not here

PostgreSQL metadata storage, S3-compatible artifact storage, remote WAL archival, encryption at rest, redaction policy, and tenant isolation are not implemented. Do not infer them from the storage interfaces or protocol registry.