Skip to main content
SQLBuild keeps execution facts separate from human output. Do not parse terminal text to determine whether work started, completed, failed, skipped, or retried. Human-readable CLI output remains the normal operator interface. Structured records are a separate contract for integrations and durable consumers.

Lifecycle envelope

New events use lifecycle schema version 2:
event_id is the immutable deduplication identity. invocation_sequence is unique and increasing in synchronous publication order within one invocation, including concurrent workers. A sink may prioritize delivery, so consumers reconstruct invocation chronology by sorting this field rather than relying on arrival timestamps. Schema-version-1 events remain readable. Unknown event names and future schema versions are retained as opaque envelopes instead of being assigned invented semantics.

Correlation and privacy

Every fact has an invocation ID. Nested IDs identify a run, logical resource and attempt, non-SQL operation, and SQL statement. Orchestrators may provide bounded JSON-compatible external_context; the Dagster integration supplies run, job, step, retry, and partition values when its execution context exposes them. Lifecycle payloads exclude full SQL, parameter values, credentials, arbitrary user messages, and raw process output. Command output and local logs can contain sensitive data and require an explicit retention and access policy.

Failure semantics

A start without a terminal fact is unknown or presumed lost. Consumers must not fabricate success or failure. Sink delivery is bounded and best effort; destination failure does not change successful warehouse work, and successful delivery does not prove the command succeeded. See Typed Sinks to export lifecycle and command-output records.