Platforms

The block's schema identifier is platform::<identifier>::1.0. This page is the capability matrix and the shared block. The field contract for each block is its own spec:

These specs describe the blocks as the engine accepts them today, including every optional key. Generated JSON Schema is a build artifact. Where it disagrees with this page or a platform spec, the spec wins. opentide's usage and SDK pages link here. They do not restate the keys. Change a field here first; the implementation follows.

Requirements

• Platform identifiers MUST use the keys in the capability matrix (snake_case).
• A platform MUST be marked enabled: true in merged configuration to appear in enabled_systems().
• Deploy and validate capabilities MUST be reported honestly. A platform without a query validator MUST NOT claim query validation support.
• CrowdStrike and HarfangLab MUST NOT advertise query validation (can_validate: false).
• A typed block SHOULD set schema to platform::<identifier>::1.0. Implementations MUST accept a missing schema and MUST accept a legacy identifier (sentinel::2.4, splunk::2.0, splunk::3.0, carbon_black_cloud::3.0, and the same shape for the other platforms). The identifier is not a closed enum.
• Unknown keys on a block MUST fail static validation. The model forbids them.
• A block MUST NOT carry a vendor-assigned external id. rule_id, rule_id_bundle, and rule_id::<tenant> at the root of any block, on every platform, MUST fail with external_id_in_rule (External rule ids).
• Registry load is stricter or looser depending on the platform. Defender, Splunk, Carbon Black, and Elastic pass leftover keys on the block into the model, so an unknown key at the block root fails load as well. The Splunk loader still drops unknown keys inside scheduling other than type, expires, schedule, and timerange. Sentinel, SentinelOne, CrowdStrike, and HarfangLab drop keys the loader does not map, so those keys pass load and fail opentide validate. The Splunk aliases and Defender's quarantine_files alias are mapped before that check.
• In every field table, optional means the key may be omitted at static validation. A later sentence in that platform spec names the keys deploy or registry load still require.
• query, where the platform spec marks it required, MUST be a string and MUST NOT be empty or whitespace.
• Static validation (opentide validate) MUST enforce the Required column of each platform spec. It MUST NOT require a field only because generated JSON Schema lists it.
• A successful deploy MUST also satisfy that platform spec's Deploy section. Those checks are not static-validation failures.

Definition

Platform capability matrix

* Deploy requires a loaded deployer entry point and enabled: true in workspace configuration.

† Live only, through Kibana rule preview (/api/detection_engine/rules/preview) plus the Elasticsearch checks, against a tenant, for every language the block can carry. Elastic has no offline syntax check (elastic-1.0).

Query validation platforms

opentide validate query supports:

sentinel, defender_for_endpoint, splunk, sentinel_one, carbon_black_cloud, elastic

Query validation is a tenant check on every platform in this allowlist: opentide validate query --live. Without --live the command refuses and names --live.

Excluded: crowdstrike, harfanglab. Implementations MUST report supported: false for those two and MUST NOT invent a passing result.

What a block must contain to validate

This is the static-validation bar. Deploy adds the constraints in each platform spec.

Shared platform block

Every block includes these fields. Platform specs do not repeat them except where deploy treats one differently.

schema is the YAML key. The model field is platform_schema because schema would collide with the base model's schema method.

Platform configuration location

Workspace TOML enables a platform and holds tenant credentials. It is not the rule block.

[platform]
enabled = false
identifier = "sentinel"
name = "Microsoft Sentinel"
description = "Microsoft Sentinel analytics rules"
flags = []

All bundled platforms default to enabled = false. Enable one by setting enabled = true under [platform]. Tenant tables, modifiers, and secrets live in the same file and are configuration, not part of platform::<identifier>::1.0.

External rule ids

Platform blocks MUST NOT contain vendor-assigned external identifiers. Defender for Endpoint, SentinelOne, and CrowdStrike use the committed deployment-state shard defined in deployment-state.md. Sentinel, HarfangLab, and Elastic use metadata.uuid; Carbon Black Cloud uses metadata.uuid for the IOC and the title for the report; Splunk uses its saved-search identity.

Elastic Security (elastic-1.0, RFC 0007) addresses every rule by metadata.uuid. Elastic never stores an external id: Kibana's internal id is not recorded in a block or in deployment state.

rule_id, rule_id_bundle, and rule_id::<tenant> are legacy keys from before RFC 0010. Static validation and every deploy path MUST reject them with external_id_in_rule, on every platform block, whether or not a shard also holds the id. No loader folds them into a field. opentide deploy migrate-state moves Defender, SentinelOne, and CrowdStrike values into shards and removes the keys from every other platform with an external_id_unused warning.

Defender also accepts the alias quarantine_files for actions.files.quarantine_file on the loader path only.

Generated schema drift

Published JSON Schema is built from the models plus a required overlay. The overlay currently names fields the model does not require:

opentide validate follows the model, not the overlay. A Sentinel block without grouping validates. Deploy of that block fails. Editor validation that consumes the generated schema may reject objects the engine accepts.

The same overlay sets a default for schema that is the legacy identifier. The model default is null, and the bundled templates write platform::<identifier>::1.0. Validation accepts both. Splunk, Carbon Black, and Elastic also set a pattern that only matches the legacy identifier shape (^splunk::[1-9]\.[0-9]$, ^carbon_black_cloud::[1-9]\.[0-9]$, ^elastic::[1-9]\.[0-9]$). That pattern rejects platform::splunk::1.0, platform::carbon_black_cloud::1.0, and platform::elastic::1.0. opentide validate does not apply it. Elastic has no legacy identifier, so its generated default elastic::1.0 names no schema that ever existed.

Splunk extras also name threshold, throttling, and security_domain on the block root, and cron and lookback directly under scheduling. Those properties are not on the model. The generator skips an extra whose property is missing. The live keys are the nested ones in splunk-1.0.md.

Entry points

Deployers register via opentide.platforms entry points. Validators load from opentide.validation.<platform>_query when the platform supports query validation.

Relationships

• rule-1.0.md — configurations blocks
• configuration.md — platform TOML merge
• deployment.md — status strategies
• validation.md — validate and validate query
• deployment-state.md — where Defender, SentinelOne, and CrowdStrike ids live
• metaschema-keywords.md — tide.config.systems::enabled, recomposition
• Platform specs linked in the Summary

Defaults & overrides

Vocabulary files are not platform configuration. See configuration.md.

Examples

• Sentinel block on a full rule: fixtures/valid/rule-1.0.yaml
• One minimal block per platform: fixtures/platforms/

History