Deployment lifecycle

Requirements

• Every rule status value MUST match a configured status name in merged deployment.toml.
• The set of statuses is configuration, not specification: implementations MUST NOT assume the bundled status names exist.
• Status ordering is NOT normative. No transition graph is defined or enforced; any configured status MAY be set directly.
• Status promotion MUST respect [promotion] settings when promotion.enabled is true.
• Deprecated statuses MUST NOT be used for new rules (opentide emits warnings).
• Platform-specific status on configuration blocks MUST also be valid deployment statuses when set.
• For Defender for Endpoint, SentinelOne, and CrowdStrike, update, disablement, and deletion MUST use the tenant binding in deployment state. A RELEASE or PREVIEW action with no binding MUST NOT create a remote rule unless the deployment-state destination is not ignored and the binding can be durably retained.
• opentide deploy MUST select only the rule files placed directly in the configured rules directory (paths.objects.rule, see workspace layout). A rule file in a subdirectory of that folder MUST NOT be deployed.

Definition

Status entries ([[statuses]])

Bundled statuses

Strategy semantics

The strategy on a status determines what opentide deploy does with a rule in that status:

No bundled status uses UNIVERSAL; a client status MAY.

Status changes and promotion

There is no lifecycle state machine. Statuses are a flat, configurable set: the only constraint enforced on a rule is that its status matches a configured status name. Any status MAY be set directly in YAML, in any order, and no transition is validated.

Promotion, when promotion.enabled is true, is a single jump — not a step along a progression:

flowchart LR
  D["opentide deploy<br/>promotion.enabled = true"] --> Q{"status strategy"}
  Q -->|"RELEASE / DISABLEMENT / DELETION"| U["status unchanged"]
  Q -->|"any other strategy"| T["status := promotion_target<br/>(default PRODUCTION)"]

Intermediate statuses are not stepped through: a rule in the bundled DESIGN status promotes straight to PRODUCTION. Promotion rewrites the status values inside a rule's platform configurations blocks.

The bundled status names in the table above suggest an editorial workflow (design → build → stage → release → retire), but that ordering is convention only and applies solely to the bundled configuration. Clients that override deployment.toml define their own statuses, and any progression between them is enforced by their own process, not by opentide.

Vendor-assigned rule ids

For Defender for Endpoint, SentinelOne, and CrowdStrike, update, disablement, and deletion require the tenant binding in deployment state (deployment-state.md). A release or preview action with no binding creates a remote rule only when the destination is not ignored and the binding can be durably retained. DISABLEMENT and DELETION with no binding report external_id_missing (a warning) and make no vendor call.

A rule that carries rule_id, rule_id_bundle, or rule_id::<tenant> on any platform block is refused before any platform client is built (external_id_in_rule). Deploy continues with independent rules and exits 1 when any selected rule reported an error. The strategies themselves are unchanged. Sentinel, Splunk, HarfangLab, Carbon Black Cloud, and Elastic address rules without a vendor-assigned id and never use deployment state.

[promotion]

[proxy]

When both proxy_user and proxy_password are present, authenticated proxy is used; otherwise host:port only.

[debug]

Top-level

Relationships

• rule-1.0.md — status field on rules and platform blocks
• configuration.md — override mechanism
• platforms/index.md — per-platform deployment
• deployment-state.md — vendor-assigned rule ids, deploy decisions, and the production write-back
• metaschema-keywords.md — tide.config.statuses keyword

Defaults & overrides

Bundled deployment.toml ships in opentide. Override via .opentide/configurations/deployment.toml. Deep merge applies.

Examples

Default rule status in fixtures: STAGING — see fixtures/valid/rule-1.0.yaml.

History