Guarantees and limits

A successful in-memory trial proves that its retained input passed the configured checks. It does not reserve a future source version or promise that a later run will see the same external data. Definition construction does not read or write sources. Execution can do both.

Lake releases preserve published versions during ordinary publication. Publication coordinates registry state and storage, but a process crash can leave intermediate objects. Inspect interrupted runs and use the lake recovery and cleanup functions before retrying. Do not assume an external target adapter provides the same transaction or recovery guarantees as a managed lake.

Output ports receive the same checked delivery in sequence. A successful primary port can remain committed if a later port fails; the run then reports an error and records each attempted port's status. Publication across ports is not atomic. Inspect port_outputs before retrying a partial delivery.

Product policies and any additional policies from options(dataraft.policies = ...) are checked at their configured validate, publish or activate event. Publish decisions, including policy ID and version, are retained in run evidence. A policy check proves only that the required metadata was present at evaluation time; organization-wide options remain session state, so record and deploy them consistently. Blocked publication does not create a successful run record.

An output SLA needs an explicit business_date and its evaluation is retained in run evidence. Meeting the calculated deadline reports when DataRaft published the output. It does not establish that a consumer could reach or read the output, or that a later dependency delivered it on time.

Local lake writes require one coordinated writer. Do not run independent local writers against the same catalog. Shared writers require the supported PostgreSQL coordination configuration; using an object store alone does not provide locking. The PostgreSQL integration job exercises separate writer processes. Backend and crash behavior still require testing against the deployment configuration.

Writer bookkeeping is process-local and keyed to the connection configuration. A future or targets worker must open its own resources and close those it owns. Do not serialize live database connections into workers. Definitions are ordinary R values; closures supplied by users can themselves capture mutable state.

“Immutable” describes normal release publication, not a legal retention policy or undeletable storage. Operators must define retention for data, registry metadata, quality evidence, frozen reports, backups and downstream catalogs. Deleting one release does not erase its copies. Resolve deletion requests across those stores; DataRaft does not provide a universal subject-erasure operation.

What validation establishes

A declared contract checks its schema and configured constraints. Without a contract, schema and type evidence is unvalidated, including reports and release metadata. Non-empty checks and explicit quality rules can still run. Execution status (completed or published) and validation status are separate facts. Warnings permit publication by design and are not equivalent to passed checks.

Generic targets receive the in-memory snapshot that was checked. Lake execution materializes candidates before checking and publication. These paths close the check/write gap; arbitrary adapter writers remain responsible for writing the provided snapshot without rereading the original source. Materialization and integrity verification currently require memory proportional to the release.

Static inspection of random/time calls and repeated rule evaluation catch common nondeterminism. Dry runs always repeat the checks. Productive runs reuse a positive comparison for the same serialized rule definition within the current R session; new or changed rules are verified before entering the bounded cache. Only the rule digest and a comparison flag are cached, never rows or approvals. A new R session starts empty. They cannot prove arbitrary R code pure or detect every external state change. Explicit dynamic references remain non-cacheable. Volatile checks are labelled and excluded from cache reuse and frozen-report approvals. Neither classification turns an external service into a reproducible input.

Release integrity and maintenance

New releases record a SHA-256 digest of typed row content, independent of row order and including duplicate rows. dataraft.lake::dr_verify_releases() checks content, existence, originating runs and registry identity. Old releases without a recorded baseline are unverifiable; migration does not retroactively certify them. The digest is not a signature. A database administrator able to rewrite both data and evidence can defeat it. Use access control and independently retained evidence when that threat matters.

The local DuckDB registry enforces unique run and release identities with indexes. DuckLake does not support those indexes: cooperating DataRaft writers check uniqueness under catalog coordination, and verification detects duplicates. Direct DBI writes bypass that protocol. Do not describe it as a database constraint on DuckLake.

PostgreSQL-backed publication, ingestion, recovery, cleanup and snapshot expiration share a catalog-level advisory lock. This intentionally serializes independent assets as well as maintenance. Optimistic parent checks remain inside publication transactions. Local deployments still require a single coordinated writer. Failed publication attempts remove uncommitted candidate tables when the process can run cleanup; a killed process requires dataraft.lake::dr_interrupted() and dataraft.lake::dr_recover(). Cleanup recognizes quarantine candidates and preserves recorded releases.

Adapter and IDE boundaries

Adapters must document atomicity, retries and partial failures for their backend. dataraft.adapters::dr_test_adapter(failure_probe = ..., read_committed = ...) can exercise a specified injected failure and assert committed output is unchanged. A passing probe does not establish every possible crash or backend failure mode.

The IDE bridge confines contract reads to the canonical contract_root supplied by trusted R code, resolving symlinks and path components before containment checks. Response writes have their own trusted root. These boundaries limit the bridge protocol; they are not a sandbox for arbitrary code in the R session.