Refund & Dispute Decision Assistant · Documentation
Architecture
Refund & Dispute Decision Assistant's pipeline, its owned data, the events it emits/consumes, and what is out of scope.
← Refund & Dispute Decision AssistantDeterministic policy floor + one metered stage
The recommendation runs through one metered stage, policy-recommendation — Cloud claude-haiku-4-5 (cost-capped, fail-closed) or OSS qwen3:8b recorded on local M4 hardware at $0, prototype default OSS-only. The policy matrix (recommendFor) is the authoritative deterministic floor: double-charge → full, service-failure → up to 50%, cancellation → full if flexible else ~70%, fraud-reversal → full, non-refundable no-show → deny. The model read informs the wording and confidence, not the policy outcome. The stage writes a cost_ledger row visible only in the inspector.
Owned data, events + simulated money
The app owns demo_eco_c6_refund_case (booking, partner, guest, reason, amount, recommendation, recommended amount, rationale, confidence, decision, note, linked risk-signal id, dispute flag). It emits refund.requested, refund.decided, and payment.captured (refund, simulated), and consumes dispute.opened from #18. The data invariant holds — owner canonical, viewer recommendations and decisions credential-scoped, ephemeral, and reset-clearing (setWhere-guarded). The refund payout and confirmation are simulated and labelled; honesty is inspector-only. Stage-2 reads demo_eco_c6_refund_case behind the same surface.