Validation

Requirements

• opentide validate MUST run default checks: id-uniqueness, uuid-format, schema.
• Schema validation MUST load each object via metadata.schema and validate against the registered Pydantic model.
• Vocabulary validation MUST walk metaschema tide.vocab annotations for each object type.
• UUID values MUST be UUID version 4.
• Object UUIDs MUST be unique across the workspace registry.
• Cross-object references MUST resolve to existing objects when checked.
• Threat chaining relationships MUST reference valid targets when checked.
• Query validation MUST only be offered for platforms in the query-validation allowlist (see platforms/index.md).
• Platforms without query validators MUST return supported: false — not fake success.
• The schema check MUST report external_id_in_rule for rule_id, rule_id_bundle, or rule_id::<tenant> at the root of any platform block and MUST suppress the redundant generic unknown-key diagnostic for that same field.
• Full-workspace validation MUST validate every deployment-state shard under .opentide/states/deployment/, including orphan shards whose object_uuid is not in the registry. A missing shard is not an error.

Definition

Check types (ValidateCheck)

Schema check sub-steps

When schema is enabled, for each in-scope object the implementation MUST, in order:

1. Load and model-validate — resolve the object's metadata.schema and validate it against the registered model.
2. Vocabulary — check controlled-vocabulary fields against the indexed metaschema vocabulary annotations.
3. Deprecation — flag deprecated fields as warnings.
4. References — resolve references links to existing objects.
5. Chaining — resolve chaining relationships (threat vectors only).

The model-validation step reports a legacy external-id key as external_id_in_rule rather than as an unknown key (platforms/index.md). The key is checked at the root of every platform block only; a key of the same name nested inside alert, query, exclusions, or another field is not a legacy key.

Steps 4 and 5 resolve cross-object links; they run whenever the schema check runs against a full workspace scope where the referenced objects are present.

Validation scope

When --file, --uuid, or --type filters match no objects, validation MUST emit a scope_no_match error rather than silently passing — a filter that selects nothing is treated as a mistake, not a success. With several --file targets, validation MUST fail when any one of them matches no object, even if the others do. The production write-back relies on this to commit only rule files that were actually validated (deployment-state.md).

Deployment state

In full scope, validation MUST read every *.json file under .opentide/states/deployment/ and report the deployment-state codes: deployment_state_shape, deployment_state_platform, and deployment_state_uuid_mismatch (including two files that canonicalise to one uuid). Orphan shards are validated like any other. A rule with no shard is not an error. narrow scope MAY check only the shards of the selected rules plus any shard file passed directly.

Platform advisories

A platform spec MAY list advisories: conditions that validation SHOULD report as a warning without rejecting the rule. Each has a stable code, and the CLI and editors MUST report a finding under that code. Codes are unique across platform specs: a later spec MUST NOT reuse a code for a different condition, and picks a new one instead. An advisory never sets VALIDATION_ERROR_RAISED.

The conditions and their reasons are in elastic-1.0.

Query validation

Command: opentide validate query --platform <id> --live

Requires platform credentials and enabled configuration. Validates deployed or planned rule queries against the live platform API. Query validation is a tenant check on every platform in the query-validation allowlist above: without --live the command MUST refuse and name --live, and MUST NOT report a pass. crowdstrike and harfanglab report supported: false instead (platforms). No platform has an offline syntax check; Elastic's query language (KQL, Lucene, EQL, or ES|QL) comes from each rule's block: its type, and language for the types that take one.

Specifications-repo fixture checker

This repository’s CI (scripts/object_fixtures.py) is not opentide validate. It proves object-spec field types against fixtures without a Pydantic runtime. Codes below are checker codes; they are distinct from the ValidateCheck identifiers (uuid-format, schema, …).

Deployment fixtures (scripts/deployment_state_fixtures.py) are checked against schemas/deployment.state.1.0.schema.json plus the filename rules the schema cannot see. Each invalid shard fixture is checked under the shard filename the checker assigns to it (a uuid that differs from object_uuid for uuid-mismatch.json, the uppercase spelling for noncanonical-uuid.json, the valid name otherwise). The valid shard must be byte-identical to writer output, and no rule fixture in fixtures/valid/, fixtures/platforms/, or fixtures/cross-object/ may carry a legacy external-id key.

Sharing fixtures (scripts/sharing_fixtures.py) also prove the merge rule: override.toml merged by name onto sharing.toml MUST equal merged.toml.

On a rule's configurations.elastic block the checker applies three of the Elastic constraint codes, the ones the invalid Elastic fixture exercises: language, esql_source, and suppression_shape. They are the platform's own codes, so the checker and opentide validate report the same name. The other Elastic codes, and every other platform block, are left to opentide.

On a rule's response.procedure.searches[] the checker reports search_language when language is set with a system other than elastic, or with a value other than kuery, lucene, eql, or esql (rule-1.1).

A packed semicolon string that happens to start with a valid token MUST still fail packed_vocab_string. Accepting only the first token is lossy and non-compliant.

Issue severities

Environment signals

Parallel execution

Validation MAY parallelize per-object work and ID scans; worker count is resolved from object count and optional --workers flag.

Relationships

• metadata.md — UUID and schema requirements
• versioning.md — schema routing at validation time
• vocabularies/format.md — vocabulary conformance
• metaschema-keywords.md — tide.vocab, tide.meta.deprecation
• platforms/index.md — query validation allowlist, external rule ids
• deployment-state.md — shard format and diagnostic codes
• Object specs — field requirements validated by Pydantic

Defaults & overrides

Validation uses merged configuration for vocabulary and status enums. No separate validation config file. Scope defaults to full workspace.

Examples

History