Governing configuration

The deployment's governing configuration defines what the task may do and what evidence Integrity must review. Treat it as versioned configuration, not a prompt that tools can override.

Constitution and task scope#

Describe the intended task, protected constraints, and permitted resources. Keep the provider connection and executor action schemas consistent with those instructions. User messages, retrieved text, and tool results remain evidence within that scope.

Call, token, and time budgets#

Customer inference and Integrity review have separate limits. A correction consumes the relevant budget; it is not a free retry. Session limits also bound work across multiple requests. Use the limits recorded for the deployment and session rather than assuming a global default.

The current connection cannot report native review token usage or its derived price. Missing accounting remains unknown. Customer-model usage must satisfy the supported protocol contract.

Apply changes through available controls#

Workspace permissions and connection capabilities determine which controls are available. An authorized configuration change has a recorded revision. Existing sessions retain their governing provenance; they require an explicit supported transition rather than silently adopting every edit.

The current Base connection has no customer-version training, activation, or rollback. For current limits see Versions and adaptation; for correction behavior see Corrective feedback.