SOP Engine

SOPs are not files. You create one by posting its definition to the API, and the engine assigns it an id. There is no repository of SOP files to keep in sync and no need to build your own version control around them.

POST /api/v2/sops
GET  /api/v2/sops/{id}
PUT  /api/v2/sops/{id}          # auto-increments the version
POST /api/v2/sops/{id}/rollback?target_version=N

Every update increments the version and preserves the previous one, so history is retained and you can roll back to any earlier version. To pin a specific version when invoking an SOP, reference it as sop:<uuid>:<version>; omit the version to use the latest.

Definitions are JSON. A v2 SOP declares spec_version: 2, runs in dag mode, and lists nodes that route to each other via next. An input_schema (JSON Schema) states what the SOP requires.

{
  "name": "Email Summarizer",
  "definition": {
    "spec_version": 2,
    "mode": "dag",
    "nodes": [
      {
        "id": "summarize",
        "type": "llm",
        "inputs": { "prompt": "Summarize: {{input.text}}" },
        "save": { "run.state.summary": "{{summarize.output}}" }
      }
    ]
  }
}

Values flow between nodes through template references ({{input.text}}, {{summarize.output}}), and save writes results into run state for later nodes to read.

Invoking an SOP creates a job rather than blocking the request. Jobs run in parallel, report status as they progress, and can be cancelled. Poll GET /api/v2/jobs/{id} until the job reaches a terminal state.

• SLAF Framework — the validation model behind SOP output.
• API Reference — full request and response schemas.