Reliability, concurrency and recovery
Retry design follows the side effect rather than repeating every request blindly.
Idempotency and replay
Proposed keys bind tenant/project + operation + key; canonical bodies must match. Same key/body returns a retained result; changed body returns 409. Confirm retention/window; Explorer retains only page-session state. This does not demonstrate backend exactly-once delivery.
Versions and partial failures
expectedVersion prevents correction overwrites; conflicts return 409 and require rereading before merging. Asynchronous jobs need per-object outcomes. Cancellation stops pending work only; already-moved paper requires physical reconciliation.
Bounded retries
Retry eligible 429/503 after provider-defined delays with backoff/jitter; correct permission/schema errors first. Deduplicate events by eventId and compare versions for ordering. Exhausted budgets enter exception/DLQ handling and audited reconciliation.
Continue the workflow
Two journeys, one records lifecycle
Connect paper and born-digital records through persistent identifiers, policies and evidence.
Read detailsIntegration quickstart
Exercise ingest → job tracking → registration → verification with synthetic data.
Read detailsIntegrity, provenance and evidence
Each evidence type answers a different question; hashes, timestamps and approvals are not interchangeable.
Read detailsStart with a verifiable scope.
Agree record classes, quality criteria, permissions and evidence before scaling.
Plan assessment