Specifications

What a Tide object is, how the object families chain, and how to read the normative opentide specifications.

These are the normative specifications for opentide — the contract that every detection object, tool, and agent relies on. The opentide package implements this contract; the generated JSON Schema is a build artifact, never the source of truth. Each spec is versioned independently — there is no framework-wide version.

Writing detections rather than the spec? Start with Usage → Object model for the hands-on view. These pages are the precise, normative reference behind it.

What is a Tide object?

Detection content in opentide is a small graph of typed objects, each a YAML file with a shared metadata block. Three families exist:

Family	Schema	Answers	Spec
Threat	`threat::1.0`	What do we defend against?	threat-1.0
Objective	`objective::1.0`, `objective::1.1` (draft)	What are we trying to detect? On 1.1 a signal may `reuse` one defined on another objective already in the repository.	objective-1.0, objective-1.1
Rule	`rule::1.0`, `rule::1.1`	How do we detect it, on which platform?	rule-1.0, rule-1.1

How objects chain

Objects reference each other by UUID. References point from rule to objective to threat; detection coverage flows the other way. On objective::1.1 (draft, RFC 0011), a reuse binding also covers the objective that owns that signal, and every other objective that reuses it. That coverage is indirect and partial. The rule still has one detection_model.

flowchart LR
  Rule -->|detection_model| Objective
  Objective -->|objective.threats| Threat
  Threat -. "is covered by" .-> Objective
  Objective -. "is implemented by" .-> Rule

Two version fields

Every object declares both, and they are independent:

metadata.schema (e.g. rule::1.0) — the structural revision, selecting the validation model. See versioning.
metadata.version (e.g. 1.2.0) — the instance content version; git is the authoritative history.

Where things live

Artifact	Location
Normative specs	this section, `specs/`
Conformance fixtures (valid/invalid YAML)	`fixtures/`
Canonical vocabularies (allowed values)	`vocabularies/`
Implementation	opentide Python package

Reading order

flowchart LR
  overview["This overview"] --> conf["Conformance (MUST/SHOULD/MAY)"]
  conf --> meta["Metadata"]
  meta --> obj["Object spec (threat / objective / rule)"]
  obj --> val["Validation"]

Conformance — how to read the normative keywords.
Metadata — the block every object shares.
The object spec you care about — threat, objective (1.1 draft), or rule (rule::1.0 remains valid).
Validation — what the engine checks and when.
A platform schema, when you are writing configurations.<platform> — start at Platforms, then the block you deploy (for example Sentinel).

Full index

The spec index lists every active spec, its version, and status. Core infrastructure specs cover workspace layout, configuration, deployment, platforms, metaschema keywords, and vocabularies. The eight platform::<identifier>::1.0 field contracts live under Platforms.

Changes follow the process in Governance.