Projects

Settings

How project overrides, workspace defaults, effective values, and integration bindings are resolved.

Updated 2026-08-06Markdown source

Project Settings contains module-specific configuration and project integration bindings.

Stored and effective values

A project can override supported workspace defaults. The project-override/workspace-default precedence is explicit: the effective value is resolved in this order:

  1. A project override, when present.
  2. The workspace default.
  3. The product default.

Settings surfaces and Chat identify the source record and whether the value can be overridden. Clearing a project override returns the project to the current workspace or product default; it does not copy that fallback into the project.

Experiment and discovery settings

Supported settings include the blog path, minimum impressions per day, eligible position band, discovery and rank cadence, cooldown, decision policy, and Autopilot behavior. Model and rank-source policy are managed by SERPclimber.

Changes affect future discovery, drafting, ranking, and automation. Existing running experiments keep their current stored lifecycle state unless a separate experiment action changes it.

Integration bindings

A connection belongs to the workspace; a binding selects which connected resource a project uses. Project Settings can bind a Google Search Console property, Wix site/resource, Cloudflare zone, or GA4 property. Credentials for those user-managed services are created and repaired only through the secure Integrations UI.

Changing a binding can change the source read by analysis or the destination used for publishing. Review the exact resource in the confirmation before applying it.

Chat can inspect effective Project settings with their product-surface, project, workspace, or built-in provenance. It can also read raw Workspace Experiment defaults without a selected project and batch supported changes into one confirmation.