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.

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.