Refund & Dispute Decision Assistant · Documentation

Business Problem & Solution

The problem Refund & Dispute Decision Assistant solves in the hospitality ecosystem and how this downscaled demo proves it.

Refund & Dispute Decision Assistant
a casethe systema recommendationdouble-charge / failurebooking contextthe refund policydecision assistantpolicy floor + modelapprove / partial / denyan amount + rationaleowner decidesconsistent, policy-aware calls
Live diagram — the policy matrix is the authoritative deterministic floor; the metered model informs the wording, not the outcome.

Consistent, policy-aware refund calls

Refund and dispute cases need a consistent answer, fast: a double-charge is a full reversal, a service failure is goodwill up to a cap, a cancellation depends on the rate's flexibility, a confirmed fraud is a reversal, a non-refundable no-show is a denial. Doing this by gut invites inconsistency and policy drift. The assistant gathers the booking context and the active refund policy and produces a recommendation — approve / partial / deny, with an amount, a rationale, and a confidence — that a human owner then decides.

What this proves — and what is simulated

It proves a policy-aware recommendation with a human-in-the-loop decision, and a clean cross-app loop: a confirmed fraud signal (#18) auto-opens a linked dispute case here. The policy matrix is the authoritative deterministic floor; the metered model rides on top. The refund payout and its confirmation are simulated and labelled, and the recommendation runs on a recorded OSS model at $0 by default.

Business Problem & Solution · Refund & Dispute Decision Assistant · Abhishek Saxena