SOP Syntax Reference

SOP definitions are loaded from subdirectories under sops_dir. When sops_dir is omitted from config, CLI commands fall back to <workspace>/sops for offline inspection, but runtime SOP execution is disabled.

1. Directory Layout

<workspace>/sops/
  deploy-prod/
    SOP.toml
    SOP.md

Each SOP must have SOP.toml. SOP.md is optional, but runs with no parsed steps will fail validation.

2. SOP.toml

3. SOP.md Step Format

Steps are parsed from the ## Steps section.

## Steps

1. **Preflight** — Check service health and release window.
   - tools: http_request

2. **Deploy** — Run deployment command.
   - tools: shell
   - requires_confirmation: true
   - input: {"type":"object","required":["version"],"properties":{"version":{"type":"string"}}}
   - output: {"type":"object","required":["digest"],"properties":{"digest":{"type":"string"}}}
   - next: 3

Parser behavior:

• Numbered items (1., 2., ...) define step order.
• Leading bold text (**Title**) becomes step title.
• - tools: maps to suggested_tools.
• - requires_confirmation: true enforces approval for that step.
• - allow-tools: and - deny-tools: define an explicit per-step tool scope.
• - input: and - output: attach JSON Schema-like step boundary contracts.
• - next: and - depends_on: route non-linear runs. Ineligible routed steps are marked skipped and leave the run pending instead of dispatching.
• - on_failure: accepts fail, retry:<count>, or goto:<step> and is enforced for reported step failures and output schema failures.
• - mode: overrides the SOP execution mode for that step.

Step Contract Enforcement

Step contracts are optional. When present, input and output accept a compact JSON object with type, required, properties, and items fields. The supported primitive types are object, array, string, number, integer, boolean, and null.

The [sop] config controls enforcement:

Schema enforcement fails closed: invalid step input prevents the step from starting, and invalid step output is routed through the step's on_failure policy. Routing enforcement replaces linear current_step + 1 advancement in LLM and deterministic runs. Tool-scope enforcement narrows the live step turn's available tools and blocks scoped-out calls at dispatch.

Untrusted trigger topic and payload text is capped, normalized, screened, and framed before it reaches step context. Framing is always on; the warning text can be hidden, but raw external trigger text is not interpolated into the model context.

Procedural memory is opt-in. When enabled, sop_workshop can create and inspect stored SOP proposals, capture completed run context into a candidate procedure, and apply an approved proposal to SOP.toml/SOP.md. Write-back only happens through the explicit apply action.

4. Trigger Types

{{#sop-trigger-index}}

For the live-versus-unwired status of each source and the transport details, see SOP Fan-In.

5. Condition Syntax

condition is evaluated fail-closed (invalid condition/payload => no match).

• JSON path comparisons: $.value > 85, $.status == "critical"
• Direct numeric comparisons: > 0 (useful for simple payloads)
• Operators: >=, <=, !=, >, <, ==

6. Validation

Use:

sh

zeroclaw sop validate
zeroclaw sop validate <name>

Validation warns on empty names/descriptions, missing triggers, missing steps, and step numbering gaps.