Policy Guide

Data quality, reconciliation, and data cadence (freshness) policies in ADOC are catalog rules. This guide covers discovering policies, listing executions, starting runs (full, incremental, or selective), and reading status, results, and cancellation from Python.

Related product docs: For hard-linked vs. soft-linked policy behavior, see Pipeline Run Details in the ADOC User Guide documentation.

Get a Policy, List Policies, List Executions

Typed resources are also available for a single rule (data quality, reconciliation, or cadence):

Starting a Run (Full, Incremental, or Selective)

Pass PolicyExecutionInput as the run payload on execute_policy, execute_dq_rule, execute_reconciliation_rule, or execute_freshness_rule. Set PolicyExecutionType to choose how data is scoped:

The sections below show markerConfigs, optional Spark settings, and related fields where they apply.

Selective runs always need one row per asset slice: the catalog asset ID, plus how to bound the data (numeric ID range, date/time window, file events, Kafka-style timestamps, and other marker types the catalog supports).

• For ID-bounded slices, use bounds_id_marker_config.

• For other cases, use the matching *_marker_config helper in acceldata.services.marker_config that pairs with the generated *MarkerConfig class (names align — for example, BoundsDateTimeMarkerConfig → bounds_date_time_marker_config), or set type= with marker_type_for (see API_TYPE_BY_MARKER_CLASS).

Wrap the result in MarkerConfig(...), and pass a List[PolicyExecutionMarkerConfig] as markerConfigs on the request.

execute_policy (Sync and Async) and the Run Handle

acceldata-sdk-python exposes AdocClient.execute_policy, which executes policies both synchronously and asynchronously. The method returns an Executor instance, on which you can call get_result and get_status to obtain the execution's result and status.

get_result() is always synchronous (it is not Python async/await): the calling thread blocks in a poll loop until the run reaches a terminal status, until total_retries non-terminal poll rounds are exhausted (default -1, unlimited), or until repeated result fetches fail (optional transient retries apply per fetch). sleep_interval (default 5 seconds between polls) and failure_strategy apply to Executor.get_result / get_execution_result. FailureStrategy.DoNotFail only controls whether the client raises on terminal WARNING or ERROR outcomes; it does not make get_result non-blocking.

Parameters for Executing Policies (execute_policy)

The required parameters include:

failure_strategy takes an enum of type FailureStrategy, with three possible values:

• DoNotFail: Terminal outcomes (including WARNING and ERROR result statuses) return an ExecutionResult without raising; HTTP or transport failures while polling yield a synthetic errored ExecutionResult. The same applies if total_retries is exhausted while the run is still non-terminal.

• FailOnError: Raises PolicyExecutionCompletedWithErrorResultError when the result status indicates a failure other than WARNING. Also raises AcceldataSdkException on HTTP or transport failures during polling when building that synthetic result. A completed run whose result status is WARNING does not raise under FailOnError alone.

• FailOnWarning: Raises PolicyExecutionCompletedWithWarningError when the result status is WARNING. It does not by itself raise on ERRORED or other error result statuses; use FailOnError for exceptions on failed (non-warning) completions.

The execution result is available through get_policy_execution_result on AdocClient, or get_result on the Executor instance returned from execute_policy; both return an ExecutionResult (or equivalent result object) when the run finishes.

Additional keyword-only parameters on execute_policy (not in the table above, but supported by this SDK):

Parameters to Retrieve Policy Execution Results

The required parameters include:

Note: For more information on hard-linked and soft-linked policies, see the ADOC product documentation for rules and executions (also noted under Related product docs at the top of this guide).

get_policy_execution_result also accepts an optional transient_retry for transient HTTP failures during polling. It waits until the run completes or the fetch fails — there is no poll-round cap on this method.

Status: Client Methods and Executor.get_status

To get the current status, call get_policy_execution_status on AdocClient, or get_status on the Executor returned from execute_policy. Both report status for the same execution ID as result polling.

The required parameters for get_policy_execution_status include:

Note: get_status on the Executor does not take any parameters; it uses the execution ID from the run that execute_policy (or Executor.execute) already started.

Asynchronous Execution Example

The snippet assumes a configured AdocClient client, as shown earlier in this guide.

Synchronous Execution Example

Same client assumption as the asynchronous example.

Cancel Execution Example

When the execution ID is already known (for example, from another system), use get_policy_execution_status and get_policy_execution_result on AdocClient with that ID and the correct RuleType.

Stopping a run: call cancel() on the same Executor handle. Typed policy resources may also expose a cancel_execution helper for the same purpose.

Other ways to start a run: execute_dq_rule, execute_reconciliation_rule, and execute_freshness_rule accept the same request shape; use the matching get_*_rule_result or get_policy_execution_result helpers to poll by execution ID.

Trigger Policies: Execution Request

Note: Execution options (markers, Spark, rule items, and so on) depend on the ADOC catalog version. Keep your acceldata-sdk-python version aligned with the server.

Pass a PolicyExecutionInput to execute_policy, execute_dq_rule, execute_reconciliation_rule, and execute_freshness_rule (the same parameter names appear in the code examples).

Use PolicyExecutionInput to:

• Set how much data runs: FULL, INCREMENTAL, or SELECTIVE (through PolicyExecutionType).

• For SELECTIVE, pass markerConfigs so each asset slice has bounds (see the ID, date/time, file event, and timestamp-based examples in this guide).

• Optionally narrow which rule items run, link a pipeline run ID, tune Spark, or supply data quality dynamic SQL filter mappings.

PolicyExecutionInput Fields

All fields are keyword arguments except the first.

• executionType: Required first argument: PolicyExecutionType.FULL, INCREMENTAL, or SELECTIVE.

• markerConfigs: Optional. List of PolicyExecutionMarkerConfig; required for SELECTIVE in normal setups.

• ruleItemSelections: Optional. Int IDs of rule items to execute; omit to run all items. In this guide, runnable examples that set this field use PolicyExecutionType.SELECTIVE (see the ID-based data quality and reconciliation examples below).

• includeInQualityScore: Optional, default True. Includes this run in the quality score.

• pipelineRunId: Optional. Pipeline run ID to attach.

• sparkSQLDynamicFilterVariableMapping: Optional. For data quality policies with dynamic SQL filters.

• sparkResourceConfig: Optional. Spark resource limits and related settings.

• columnVariables: Optional. Column variable bindings when the policy requires them.

• sparkFilterSelectedColumns: Optional. Column names for Spark filter selection when applicable.

execute_dq_rule and execute_reconciliation_rule (Trigger Runs)

Use the same PolicyExecutionType and PolicyExecutionInput for data quality and reconciliation policies; only the client method changes (execute_dq_rule vs. execute_reconciliation_rule).

For data cadence (freshness), use execute_freshness_rule with the same request shape.

Loading a policy with get_policy(PolicyType.*, identifier) returns a typed DataQualityRuleResponse, ReconciliationRuleResponse, or DataCadenceRuleResponse, each with a nested rule object — use policy.rule.id in execute_*_rule (as shown in the snippets below). With get_policy(identifier=...) and no PolicyType, the client returns a QualityRule; use policy.id (there is no policy.rule on that type).

Data Quality Policy Execution Examples

Trigger full data quality policy: To run a full data quality policy across the entire dataset, use PolicyExecutionType.FULL on PolicyExecutionInput and call execute_dq_rule with the rule ID.

Trigger incremental data quality policy: To run an incremental data quality policy based on a configured incremental strategy, use PolicyExecutionType.INCREMENTAL. The run advances from the catalog's last stored marker for that rule. The minimal request is often only the execution type; add markerConfigs only if the catalog requires an explicit marker for this policy.

Trigger selective data quality policy: To run a selective data quality policy over a subset of data, as determined by the chosen incremental strategy, sparkSQLDynamicFilterVariableMapping and sparkResourceConfig are available, as shown in the optional example below. sparkSQLDynamicFilterVariableMapping applies only when the data quality policy includes SQL filters.

ID-Based Selective Policy Execution

Uses a monotonically increasing column value to define data boundaries for policy execution, implemented with BoundsIdMarkerConfig. Optional Spark tuning and sparkSQLDynamicFilterVariableMapping apply when the data quality policy uses dynamic SQL filters. Optionally pass ruleItemSelections with catalog rule item definition IDs to run only those checks within the selective slice; omit the field to run every item on the policy. The same ruleItemSelections argument applies on execute_reconciliation_rule and execute_freshness_rule PolicyExecutionInput objects.

DateTime-Based Selective Policy Execution

Uses an increasing date column to define data boundaries for policy execution, implemented with BoundsDateTimeMarkerConfig.

File Event-Based Selective Policy Execution

Uses file events to establish data boundaries for policy execution, implemented with BoundsFileEventMarkerConfig. The date_column_name field must match a column on the bound asset (replace event_date with the actual column name).

Kafka Timestamp-Based Selective Policy Execution

Uses offsets associated with specified timestamps to set data boundaries for policy execution, implemented with TimestampBasedMarkerConfig.

Reconciliation Policy Execution Examples

Trigger full reconciliation policy: To trigger a full reconciliation policy across the entire dataset:

Trigger incremental reconciliation policy: To trigger an incremental reconciliation policy based on a configured incremental strategy:

Trigger selective reconciliation policy: To trigger a selective reconciliation policy over a subset of data, constrained by the selected incremental strategy:

ID-Based Selective Policy Execution

Uses a monotonically increasing column value to define data boundaries for policy execution, implemented with BoundsIdMarkerConfig. The asset_id in the marker configuration denotes the unique identifier of the underlying asset the reconciliation policy is based on. This can represent either the left or right asset ID.

DateTime-Based Selective Policy Execution

Uses an increasing date column to define data boundaries for policy execution, implemented with BoundsDateTimeMarkerConfig.

File Event-Based Selective Policy Execution

Uses file events to establish data boundaries for policy execution, implemented with BoundsFileEventMarkerConfig. Use a real date_column_name for the backing asset (same note as for data quality file-event markers).

Kafka Timestamp-Based Selective Policy Execution

Uses offsets associated with specified timestamps to set data boundaries for policy execution, implemented with TimestampBasedMarkerConfig.

What's Next

After you complete this section, explore:

• Tags and Labels – Learn how to attach tags and labels to the assets these policies run against.

• Pipelines Guide – Learn how to link a policy execution to a pipeline run using pipelineRunId.