What should a sample specification list for generated mismatch environment state?
A checklist of the items a buyer can name, from record families and cause classes to tool actions and end states, so generated state fits their environment.
A useful sample specification names the following, so the generated state can be built to fit your environment and your tool set.
- The two systems or record families that must disagree, and the keys that link them. - The cause classes to plant, and which should be easy, hard or deliberately undeterminable. - Tolerance and approval policies, stated as readable rules with amounts and roles attached. - Supporting records per case, such as adjustment history, correspondence, approvals and prior cases. - The noise to include, such as truncated references, duplicate customers, mixed date formats and stale statuses. - The tool actions your environment exposes, so end states are expressed in your own terms. - The acceptable and unacceptable end states for each case, with a short written rationale. - The domain and vocabulary level, such as insurance premium ledgers or freight invoices.
A specification that names keys, causes, policies and tools lets the generated state fit your harness the first time, not after rework.
- Audience:
- Environment builders
- Content type:
- Checklist
- Buyer question:
- What can be generated
Content release: r-a220eb6e099b243b
Related questions
- What would a generated freight invoice versus proof-of-delivery task contain?
- What file layout and schema would a generated case set use?
- Can a pack include policies, tolerances and escalation rules, not just records?
- Which record elements should a dataset for this workflow include?
- What records and relationships can MirrorFirm generate for this workflow?
- What fields and file formats can a generated mismatch pack use?