What should I specify about environment state before requesting a release?
A checklist of the environment state decisions that most affect a generated set-up release, from entity types and near-duplicate parties to policy rules and delayed events.
Before you request a release, settle which parts of the environment state it must contain; these are the decisions that most change the result.
- Entity types required: approval, party, account or service, obligation, task and notice. - How many near-duplicate parties to seed per task, and how close they should be to the target. - Approval conditions and expiry rules, and which sit in structured fields versus free-text notes. - Document statuses to include, such as received, expired, missing or mismatched. - Role queues, and the handover message each role receives from the one before. - Policy rules, written as checks a grader can execute against the final state. - The share of tasks whose correct outcome is a referral, pending status or rejection. - Later events, such as a first invoice or claim, that reveal earlier mistakes.
Deciding these items up front turns a vague request into a release you can load, run and grade with little rework.
- Audience:
- Environment builders
- Content type:
- Checklist
- Buyer question:
- What can be generated
Content release: r-a220eb6e099b243b
Related questions
- Can a simulated environment include tool errors and incomplete approvals?
- What does a generated task with a seeded fault look like for policy issue?
- What file formats, schemas and tool actions can a set-up release use?
- What records, relationships and policies can a generated set-up release contain?
- What should a buyer specify when requesting a generated set-up release?
- What might the record schema look like for generated set-up state?