Where does a sufficiency gate fit in a model training or evaluation pipeline?

Treat the sufficiency gate as one step with a clear contract.

**Inputs**

- `case_id` and `case_type` - `policy_id` and `policy_version` - a list of `document` objects with `doc_id`, `doc_type`, `issued_date`, `signed`, `entity_ref`, and either `text` or `fields` - optional `history`, which is earlier messages and requests on the case

**Outputs**

- `decision`: one of `proceed`, `request`, `escalate` - `gaps`: a list of `{requirement_id, reason, doc_id_or_null}` - `request`: `{recipient_role, items[], channel, body}` when the decision is `request` - `status_after`: the case status the decision sets

**Links**

Each gap points to a `requirement_id` in the policy, and each requirement points to the clause text. Each document points to its case. A request points to the gaps it covers, so a later turn can check whether the reply resolved them.

**Formats**

A release can ship cases as JSONL, one case per line with documents nested, and policies as a separate JSONL or Parquet table. Gold labels sit in a distinct file keyed by `case_id`, so training and held-out evaluation can be split without editing case files.

In a pipeline, the gate feeds assessment only when `decision` is `proceed`. Scope the exact field names in a pilot, since they should match your harness.