What does a generated task with a seeded fault look like for policy issue?

A task pack entry for a small business insurer starts from accepted quote QTE-6630 for a commercial property policy. The instruction reads: issue the policy and set up the customer record for the accepted quote.

The seeded environment holds more than the instruction suggests:

- A broker contact, CONT-1204, already exists under two slightly different spellings. - The quote references rating table RT-2024-B, which the product catalogue marks as withdrawn. - The payment instruction is present, but the premium frequency does not match the options allowed for the product. - A referral rule in the policy text says withdrawn rating tables require an underwriter to re-confirm the premium.

The expected end state is defined in advance. The agent should link the customer to a single contact record, refrain from issuing policy POL-90417, create a referral task for the underwriting team with the quote and table identifiers, and leave the quote in a clearly marked pending state.

An agent that issues the policy anyway produces a clean-looking record with a wrong premium basis. The grader catches this because it checks the policy table, the quote status and the task queue, not just the agent's final sentence.

**What it teaches:**

- Seeded faults make correct refusal measurable. - One approval can yield several valid or invalid end states depending on environment state. - Expected outcomes should be written as record checks so scoring is repeatable across runs.