Set Rail

Compose a Spec pipeline rail so it can run via POST /v1/pipelines without the UI. Set the ordered stages and their per-stage config in one PUT.

Set the Spec composed pipeline rail. This is what makes a Spec runnable from the API: once a rail is set, POST /v1/pipelines compiles it and runs your documents through it, no UI required. The PUT replaces the stored rail wholesale, so send the full ordered list each time. Passing an empty array clears the rail.

A minimal runnable rail is a single extraction stage: {"rail":[{"type":"schema","name":"Extraction"}]}. From there you compose the stages you need in order. The compiler maps registry to transfer, schema to extraction, resolve to resolution (one phase per active policy), valid to a positional validation checkpoint, and assembly to a post-run compose.

Stages that need configuration carry it under json. A resolve stage carries json.policy_ids (the Data Policies it runs). A valid stage carries json.stage_ids (the member validation-stage ids, configured via the validation-stages endpoints) and an optional json.target_phases. An assembly stage carries json.grouping_field and json.anchor_field. The rail accepts at most 50 stages.

{
  "rail": [
    { "type": "schema", "name": "Extraction" },
    {
      "type": "resolve",
      "name": "Resolution",
      "json": { "policy_ids": ["b2c3d4e5-f6a7-8901-bcde-f23456789012"] }
    },
    {
      "type": "valid",
      "name": "Totals checkpoint",
      "json": {
        "stage_ids": ["f1e2d3c4-b5a6-7890-abcd-ef1234567890"],
        "target_phases": ["resolve"]
      }
    },
    {
      "type": "assembly",
      "name": "Compose",
      "json": { "grouping_field": "contract_number", "anchor_field": "document_kind" }
    }
  ]
}

Response

Returns { "rail": [...] } echoing the rail you set. After setting a rail, compile and run it with POST /v1/pipelines followed by POST /v1/pipelines/:id/start.

{
  "rail": [
    { "type": "schema", "name": "Extraction" }
  ]
}

Errors