Skip to content
MirrorFirm

What should a generated intake release specify?

A checklist of elements to confirm before accepting a release, from case types and exception classes through to expected outcomes and starting environment state.

When you ask for a generated release, confirm that each of these elements is defined so the material can be used for agent work.

- Case types and channels covered, such as claim lodgement by portal and by email. - Party records with deliberate partial matches, not only exact matches or clean misses. - Document types with attributes an agent must check: legibility, expiry, issuer and the party named. - Completeness and routing policies with identifiers the agent can cite. - Exception classes: duplicates, amendments, withdrawals, conflicting fields and wrong-case attachments. - Handover notes between roles, written with the gaps and shorthand staff actually use. - An expected outcome per case: status, queue, reason codes and message type. - Environment state at the start of each task, including what is already open for the same party.

A release that lacks expected outcomes can still support training data work, but it cannot support automatic grading. Ask which items are included in a sample before agreeing a larger scope.

Confirming these elements up front shows whether the material supports automatic grading or only training data work.

Audience:
Agent developers
Content type:
Checklist
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Application intake