A schedule (called a policy in the API) attaches an automated trigger to a concept so it runs without manual intervention. Two trigger types are supported: cron fires at a fixed calendar interval, and data_change polls for upstream data changes at a configurable interval and fires when new data is detected. All paths are relative to the base URL and require authentication. All responses use the standard envelope. The scope parameter follows the same scope semantics used across the platform.

Create a policy

Attach a new evaluation policy to a concept. On success the scheduler immediately registers the trigger; the concept will run at the next scheduled moment or when the data-change condition is met.
trigger_config for cron
trigger_config for data_change

Example

List policies

Return all evaluation policies for a project, optionally filtered to a single concept.
data is an array of policy objects in the same shape as the create response.

Get a policy

Retrieve a single evaluation policy by ID.
Returns 404 if the policy does not exist.

Update a policy

Change a policy’s trigger configuration or enable/disable it. Only the fields supplied in the request body are modified; omitted fields are left unchanged.

Example — pause a policy

Returns 404 if the policy does not exist.

Delete a policy

Remove a policy and cancel its scheduled job. This does not affect run history already recorded.
Returns 404 if the policy does not exist.

Trigger a policy now

Fire a policy’s concept run immediately, outside its normal schedule. Useful for testing a new policy or backfilling a missed run. The policy must exist and the trigger_now call enqueues an execution synchronously.
To track whether the triggered run succeeded, poll Run history until a new entry appears with a terminal status (success or error).

Run history

Return the execution log for a policy, ordered by most recent first. Use limit and offset for pagination.