Resolve refunds under an approved policy

Why use this

1. A support team may receive many refund requests that appear routine but differ in purchase timing, item scope or previous adjustments. Applying a rule without checking those details can produce inconsistent decisions or duplicate refunds.

2. This job could structure policy interpretation into a reviewable decision record and separate clear cases from exceptions. Explicit scope and evidence help the owner decide what may be handled under an approved policy without treating a prior rollout as unlimited transaction authority.

Why an agent / simpler alternative

Useful judgment

Match request facts to policy conditions, identify missing evidence and distinguish exceptions from routine cases.

Simpler alternative

Use deterministic support rules when eligibility is fully captured in reliable structured fields.

Unsuitable when

The policy is ambiguous, the request involves exceptional commitments or refund execution lacks appropriate authorization.

Proposed inputs

1. Name

   Refund policy

   Owner

   Business owner

   Minimum scope

   Current approved rules, limits and escalation cases

   Quality check

   Identify effective date and excluded products

2. Name

   Request/order evidence

   Owner

   Authorized support owner

   Minimum scope

   Necessary order facts and prior-refund status

   Quality check

   Check requester identity, item scope and duplicated tickets

Access and setup — proposed or unknown

Proposed minimum

1. Use fictional requests and a policy worksheet; no payment-system access, refunds or customer messages.

Compatibility unknowns

1. Current support permissions, transaction linkage, refund tooling and runtime compatibility are unknown.

External actions requiring approval

1. Refund execution and customer communications require applicable approval within explicit policy bounds; exceptions need owner review.

Expected deliverable and review checks

Proposed artifact

Policy-based decision proposal with supporting facts, unresolved conditions and a separate resolution/communication approval state.

Critical checks

1. Use the right policy version; check prior adjustments; distinguish eligibility from executed refund; avoid unapproved promises.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   Duplicate tickets request the same refund

   Why it matters

   Independent handling can repay twice

   Proposed response

   Link the cases and verify transaction history before action.

2. Signal

   A policy condition is missing

   Why it matters

   The model may fill the gap with a favorable assumption

   Proposed response

   Hold the case and ask the owner or customer through an approved route.

Effort and cost — unknown

Setup work

1. Define policy boundaries and exception handling.

Ongoing review

1. Owner reviews ambiguous cases and authorized transaction evidence.

Unknowns

1. Policy coverage, identity verification, payment behavior and support costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent four requests covering clear eligibility, a missing condition, an excluded item and a duplicate ticket; draft decisions only.

Acceptance checks

1. Link duplicates; hold unknowns; cite policy conditions; issue no refund or message.

Stop conditions

1. Stop if policy authority, transaction identity or financial-action permission is missing.

Limits

1. A policy decision draft cannot establish that money was returned or that every contractual obligation is satisfied.