What should I include in a release specification for a sufficiency task pack?
A checklist of specification items that shape a sufficiency task pack, from case types and requirement versions to labelled gaps, partial replies and held-out cases.
Use this list when drafting the specification for a task pack or dataset so the release can be scored, not just read.
- **Case types:** name the processes and variants your agent handles, such as new account, claim lodgement or onboarding. - **Requirement sets:** ask for versions per case type, including substitutes, age limits and conditional items. - **Outcome mix:** specify the share of sufficient, insufficient and escalate cases, plus borderline ones with arguable substitutes. - **Gap labels:** request each gap tied to a requirement ID and, for conflicts, to both documents. - **Reply behaviour:** include partial, late and contradictory replies to requests, not only complete ones. - **Document faults:** list the faults to include, such as missing pages, wrong entity, expired items and duplicates. - **Held-out portion:** keep a set of cases the training data never touches. - **Formats:** state the file formats and field names your pipeline expects.
Agree the exact quantities and limits in a pilot, since these depend on the scope you choose.
A specific request produces a pack you can score; a vague one produces documents without labelled decisions.
- Audience:
- Agent developers
- Content type:
- Checklist
- Buyer question:
- What can be generated
Content release: r-a220eb6e099b243b
Related questions
- Which records and relationships can a sufficiency dataset or task pack contain?
- Will a release include the documents themselves, or only metadata about them?
- What might the JSONL or Parquet schema look like for sufficiency cases?
- What would a generated insurance case with conflicting documents contain?
- How can one freight import case be expanded into controlled variants?
- Can a release include defective, stale or conflicting documents?