AuthGuard Pay

Human-governed AI evidence review with deterministic guardrails, explainable risk scoring, audit trails, and PayPal Sandbox payments.

Comment

Inspiration

Prior-authorization workflows combine documentation review, payer requirements, risk analysis, human decisions, and patient-payment responsibilities. When these activities are spread across disconnected systems, it becomes difficult to understand why a case followed a particular route, who approved the next action, and whether the payment process followed the correct controls.

We built AuthGuard Pay to demonstrate a safer model: deterministic routing first, explainable AI second, explicit human approval third, and an auditable PayPal Sandbox payment workflow last.

What it does

AuthGuard Pay processes a synthetic prior-authorization case through an 11-stage evidence-review pipeline.

The system:

  • Validates and normalizes the case.
  • Detects privacy and prompt-injection concerns.
  • Applies deterministic eligibility and documentation rules.
  • Uses XGBoost to estimate authorization denial risk.
  • Locks the workflow route using configured thresholds and guardrails.
  • Retrieves relevant guidance through local policy RAG.
  • Produces a six-agent internal evidence-review panel with SUPPORT, OPPOSE, and CAUTION findings.
  • Generates a canonical deterministic explanation.
  • Optionally uses Groq to rephrase that explanation in clearer language.
  • Requires a named human reviewer to approve the package and fixed synthetic patient-pay amount.
  • Creates, approves, and captures a PayPal Sandbox order.
  • Records human and payment actions in a timestamped audit trail.

The route is locked before Groq is called. Groq can improve the presentation of the explanation, but it cannot change the route, risk score, review requirement, payment amount, or PayPal action.

PayPal is central to the final human-governed workflow. The application requires a reviewer decision, explicit payment approval, Sandbox buyer approval, and a separate human-triggered capture action. The audit trail records:

  • APPROVE_PACKAGE_FOR_SUBMISSION
  • PAYMENT_APPROVED
  • PAYPAL_ORDER_CREATED
  • PAYPAL_CAPTURED

How we built it

AuthGuard Pay uses:

  • Python and Flask for the backend API.
  • Streamlit for the interactive dashboard.
  • Deterministic expert rules for eligibility, documentation, and workflow controls.
  • XGBoost for authorization-denial risk scoring.
  • TF-IDF policy RAG for local guidance retrieval.
  • Groq as an optional explanation-only enhancement.
  • PayPal Orders v2 Sandbox APIs for order creation and capture.
  • JSON persistence for cases, memory, reviewer decisions, and audit records.
  • Railway for public deployment.

The architecture deliberately separates routing authority from explanation. Expert rules, model thresholds, and guardrails establish and lock the route. Policy RAG, the Evidence Review Panel, and optional Groq narrative run afterward for explanation and critique.

If Groq is disabled, unavailable, or produces a response that fails validation, AuthGuard Pay automatically uses its canonical deterministic explanation.

The prototype uses only synthetic data and PayPal Sandbox. It does not determine insurance coverage, provide medical advice, submit an authorization to a payer, or process real patient payments.

Challenges we ran into

One major challenge was preventing an external language model from appearing to control the decision. We addressed this by locking the route before explanation generation, displaying the route and explanation separately, validating Groq output, and falling back to the deterministic explanation whenever necessary.

Another challenge was maintaining the PayPal order across Streamlit reruns and the external approval process. PayPal opens in a new tab and redirects that tab back to AuthGuard after buyer approval, while the pending order remains in the original Streamlit session. We documented this behavior and preserved an explicit capture action in the original session.

We also encountered a capture-time dependency issue because the HTTP client had originally been imported only inside an earlier conditional order-creation branch. A later Streamlit rerun could therefore reach payment capture without that dependency being defined. We moved the import to module scope and added a focused regression test.

Additional challenges included keeping credentials out of screenshots, distinguishing authorization-denial risk from medical risk, ensuring that panel findings could never override the locked route, and making the complete workflow understandable to a first-time reviewer.

Accomplishments that we're proud of

  • Built and deployed an end-to-end AI and PayPal Sandbox workflow.
  • Preserved deterministic routing authority while benefiting from an optional LLM explanation layer.
  • Implemented six internal advisory agents without allowing them to override guardrails.
  • Required explicit human approval before order creation and payment capture.
  • Created a four-action audit chain covering the complete approval and payment lifecycle.
  • Added automatic deterministic fallback for Groq failures and rejected explanations.
  • Produced a detailed demonstration walkthrough with nine application screenshots.
  • Built 176 automated tests without making real Groq or PayPal network requests.
  • Successfully completed a PayPal Sandbox order, buyer approval, capture, and audit verification.

What we learned

We learned that explainability becomes more trustworthy when the system clearly distinguishes:

  1. The evidence and model signals.
  2. The authoritative locked workflow route.
  3. The narrative used to explain that route.

We also learned that payment automation does not need to remove human control. PayPal can participate in an AI-assisted workflow while order creation, buyer approval, and capture remain explicit and attributable human actions.

Finally, we learned that fallback behavior should be treated as part of the primary architecture—not merely as error handling. AuthGuard Pay remains functional, understandable, and auditable even when the optional external explanation provider is unavailable.

What's next for AuthGuard Pay

Future improvements could include:

  • Persistent database storage.
  • Cryptographically verifiable audit records.
  • Role-based access control.

Built With

Share this project:

Updates

Submission history