Skip to main content
Control Loop v0.1 adds two new configuration fields (max_cascade_depth on policies and prompt_autoship_enabled on projects) and three new fields on evaluation responses (context, source_action_id, original_evaluation_id). This page explains what each default means for your existing setup and what, if anything, you need to change.

​
New fields and their defaults

​
prompt_autoship_enabled on projects

Default: false Every existing and new project has prompt_autoship_enabled set to false unless you explicitly enable it. This means all ab_passed prompt deployments wait for an owner to approve them manually before going live. Nothing ships to production automatically until you opt in. Action required: None, unless you want auto-ship. To enable it on a project, set prompt_autoship_enabled: true via PATCH /v1/projects/{id} or in Dashboard → Projects → [project] → Settings.

​
max_retry_depth on policies

Default: 3 max_retry_depth shipped in the 2026-04-30 release. If you have existing policies with action_type: retry, each one already has max_retry_depth: 3 — meaning after three retries on a single trace, the next attempt is auto-converted to an escalate action and routed to the HITL queue. If you want more or fewer automatic retries before escalation, update the value on each policy via PATCH /v1/policies/{id} or in Dashboard → Control → Policies. Valid range: 1–10.

​
New evaluation fields

Three new optional fields appear on evaluation response objects (GET /v1/eval, GET /v1/eval/{id}) as of Control Loop v0.1: Action required for existing integrations: None. These fields are additive — existing evaluations have context: "fresh" and both FK fields as null. If your code reads evaluation responses, ensure your JSON deserialiser tolerates unknown or null fields (it should already, per the API versioning policy).

​
New prompt deployment endpoints

Five new endpoints are available under /v1/prompts/deployments: These endpoints are additive and dashboard-only (Clerk session auth, Team+ plan). They do not affect existing API key integrations or SDK clients.

​
Regression detection

Evaluations triggered by a control action’s remediated trace now carry context: "remediation". When the remediation eval’s score drops below the original eval’s score (the baseline stored in original_evaluation_id), TruLayer emits a RemediationRegression failure detection event. This is a new alert type — existing failure rules and webhooks are unaffected unless you add a new rule that matches on it. Action required: None unless you want to surface regression alerts in your own tooling. If you use webhooks or the GET /v1/failures/clusters endpoint, regression events will appear automatically once the feature is active.

​
Summary checklist