Fulcrum Service Recovery

Big delivery platforms run automated customer-recovery engines in-house. A 3–30 location restaurant group handles complaints by hand, from memory, under time pressure: slow, inconsistent, and refunds drift from policy. Fulcrum Service Recovery gives small groups that capability without handing decisions to a bot. Staff paste one or many complaints, optionally attach an anonymized order CSV, and pick a versioned written policy. AMD Developer Cloud Token Factory runs DeepSeek-V4-Flash (OpenAI-compatible API, temperature 0.2, JSON-only) to extract the issue, order refs and missing facts, and to draft a reply. Deterministic code then decides what is allowed: order verification, policy caps, never-automate rules, complaint-vs-record conflicts, and prompt-injection detection. Each case becomes a manager review packet: the draft (or why none was released), evidence refs for every claim, missing facts, inference provenance (backend, model, request ref) and an audit trail. Model error, timeout or bad JSON fails closed to manager review, with no silent fallback. Managers approve, reject or request info; decisions only record an audit event. Results on the live AMD backend (20-case synthetic eval): 20/20 correct routing, 100% packet completeness, 0 unauthorized side effects; median latency 6.24 s, p95 11.50 s on the shared endpoint. Built for shared capacity: 429 backoff honoring Retry-After, request timeouts, and a dedicated MI300X provider slot ready to configure. Next: MI300X deployment, a larger eval set, an owner policy editor, and a pilot with a restaurant group on its own written policy. All data is synthetic; no refunds, messages or customer contact. Stack: FastAPI, Pydantic, SQLite, Docker.