How does a sufficiency decision map onto environment state and tool actions?

Model the workflow as a small set of linked objects and a narrow tool surface.

**State objects** - `case`: id, product, attributes that drive requirements, status, clock state - `requirement`: id, rule reference, condition, accepted document types, validity rule - `document`: id, case id, type, issue date, named party, signed flag, legibility flag, content text - `request`: id, case id, items requested, sent time, reply status

**Tool actions** - `list_documents(case_id)` and `read_document(doc_id)` - `get_requirements(case_id)` returns the rules that apply - `lookup_record(case_id, record_type)` for items already held - `send_request(case_id, items, message)` - `set_status(case_id, status)` - `escalate(case_id, reason)` - `release_case(case_id)`

**Transitions** A valid `send_request` moves the case to Awaiting Information and pauses the clock. A `release_case` on an insufficient pack is allowed by the environment but recorded as a defect, so you can score it rather than block it. Customer replies are scripted events that add, or fail to add, documents on a later step.

Keeping the tool surface this small makes trajectories comparable across runs and keeps the sufficiency judgement, not tool navigation, as the thing being tested.