The next step for opentide

opentide is a spec and an implementation. The spec is the contract for detection objects — threats, objectives, rules. The opentide package implements that spec. It is the engine you run against a detection repo.

Until now that implementation lived in your git tree as a submodule. The next step is a package you can install:

pip install opentide

Specs, usage docs, and this blog live here, at opentide.org.

The spec does not ship detections. The package does not hold your YAML. Your repo is still the source of truth for what you detect.

Why the submodule had to go

You can already write detections for Sentinel, Splunk, Defender, SentinelOne, Carbon Black, CrowdStrike, and HarfangLab. What kept breaking was sharing the implementation: it was not a version you could pin, upgrades were not reviewable, and every instance rewrote the same CI glue.

The old tree lived in the client repo as a submodule. Imports walked git to find sys.path. You pinned a SHA, hoped the next pull left Orchestration/ alone, and could not write opentide==0.4 and go home.

So we rebuilt it as a package, in a new repository. The old tree stays as history.

import sys, git
sys.path.append(str(git.Repo(".", search_parent_directories=True).working_dir))
from Engines.modules.tide import DataTide
from Engines.modules.plugins import DeployTide

rule = DataTide.Models.mdr[uuid]
DeployTide.mdr["sentinel"].deploy(...)

python Orchestration/validate.py

from opentide import Opentide

Opentide.initialise()
rule = Opentide.Rules[uuid]
rule.deploy("sentinel")

pip install opentide
opentide validate --strict
opentide deploy --platform sentinel --dry-run

What changed

You install a package, not a submodule SHA. pip install opentide, then lock it like any other dependency.

CLI, SDK, and MCP are the same package — opentide validate, from opentide import Opentide, opentide-mcp. Not three implementations, and not a pile of Orchestration/ scripts.

JSON Schema is generated from the models, so the types and the schema cannot drift. Detection content stays in your repo.

A threat is still what you defend against. An objective is still what you are trying to detect. A rule is still how you detect it on a platform. References still point rule → objective → threat; coverage still flows the other way. See the object model.

Soft cutover

1. 01

   Package on PyPI

   pip install opentide — CLI, MCP, and SDK on one package.

2. 02

   Old tree archived

   The old implementation and companion repos go read-only. Pinned checkouts keep resolving.

3. 03

   Four-week window

   Deployer bugs, docs, and migration questions. We are not adding platforms in this stretch.

We are archiving the old implementation and companion repos. History stays. Issues stay. The READMEs will point here. New work goes in the package.

Pinned submodule SHAs and existing clones keep working. Existing production instances do not have to move this week. They should move when they next touch CI.

There is no one-step opentide migrate. The migration guide is the path: drop the submodule, replace Orchestration/ with the CLI, set OPENTIDE_REPO_ROOT, run opentide validate --strict. If you would rather have someone else do the mechanical edits, there is a prompt on that page. Review the diff as if a colleague wrote it.

Four weeks

The package works. For four weeks we are not adding platforms. We will fix what you hit: validation that is too loud or too quiet, a deployer that misbehaves on a tenant you actually have, a setup wizard that writes the wrong MCP path, a migration step the guide forgot.

The old implementation ran in production for years before it was open-sourced. 0.1.0 is that same work, installable, and explicit about which platforms can check a query. Then we take four weeks of bug reports.