Imagine an HR manager who has just completed this month’s hiring drive. Dozens of candidates have accepted their offers, and everyone is eager to onboard them as quickly as possible. But before that can happen, every background verification request has to move through multiple checks, vendors, approvals, and status updates. What should be a straightforward operational process often turns into hours of chasing spreadsheets, checking vendor portals, and answering the same status questions over and over again. It isn’t a technology problem as much as it is a visibility problem — and that’s the challenge that inspired BGVerifyIQ.
The problem every HR team quietly struggles with
Ask any HR or Talent Acquisition team what happens after an offer letter goes out, and you’ll hear a familiar story. A candidate is selected. A background verification (BGV) request is raised with a vendor. And then… the waiting begins.
Behind that wait is a surprising amount of manual work:
- HR has to log into multiple vendor portals just to check where a case stands.
- Status updates live in scattered Excel sheets, emails, and vendor dashboards that rarely agree with each other.
- Nobody has a single, live number for “how many candidates are actually ready to be approved today.”
- SLA breaches — cases that have been open too long — get discovered late, usually when a hiring manager complains.
- When a discrepancy or a “suspect” flag shows up, it can get buried in a spreadsheet row instead of being escalated immediately.
- Every time leadership asks “how are our BGV vendors performing,” someone spends half a day pulling numbers together manually.
- New joiners get onboarded before their verification is even reviewed properly, simply because nobody had a clear, current view of their case.
None of this is because HR teams aren’t diligent. It’s because the tools weren’t built for this specific job. Spreadsheets don’t talk to vendor systems. Vendor portals don’t talk to each other. And nobody has time to become a SQL expert just to answer a simple question like “which candidates are stuck.”
This is the exact gap BGVerifyIQ was built to close.
What BGVerifyIQ actually does
BGVerifyIQ is a single workspace that sits on top of your background verification data — requests, checks, education records, employment records — and gives HR three things they didn’t have before, all in one place:
- A plain-English way to ask questions, without writing a single line of SQL.
- A live, always-current dashboard of the entire BGV pipeline — no manual pulling of numbers.
- A complete 360° view of any single candidate, with a clear, explainable recommendation on whether they’re ready to be approved.
- Everything in the current version is intentionally read-only. It never changes your underlying data. It only helps people see it, understand it, and act on it faster. That’s an important design decision we’ll come back to later.
Why I didn’t just build “another chatbot”
There’s a lot of excitement right now about AI agents that can answer any question in a chat window. And that excitement is well placed — for the right kind of question.
But here’s the catch: a chat window is great when you have a specific question (“what’s the status of candidate Ananya?”). It’s a poor way to see the big picture (“how many candidates are pending across all vendors right now, broken down by how old each case is?”). Nobody wants to type ten different questions into a chatbot every morning just to get their daily overview.
*So instead of picking one or the other, BGVerifyIQ combines both, deliberately, as separate pages built for separate jobs:
*
- Chat — for quick, specific, in-the-moment questions.
- KPI Dashboard — for the daily/weekly bird’s-eye view, the numbers leadership actually cares about.
- Candidate 360 — for a deep dive into one candidate before making an approval decision.
- History — because past answers and past conversations shouldn’t disappear the moment you close the tab.
- Settings — so each user can control their own experience and see exactly which AI models are answering their questions.
This “agent + dashboard” hybrid is, in our view, the right shape for most internal business tools going forward. The agent handles the ad hoc and the unexpected. The dashboard handles the routine and the recurring. Neither replaces the other.
A tour of the app
💬** Chat**
This is where a user can type something like “show me approval-ready candidates” or “any updates on Rao” in completely normal English. Behind the scenes, the question is turned into a safe, read-only database query, run against the data, and answered with a short summary plus the actual table of results underneath — so nothing is ever “just trust the AI,” the numbers are right there to verify.
Three quick-action buttons — Priority Queue, SLA Breaches, Vendor Performance — skip the AI translation step entirely and jump straight to pre-built, always-correct answers for the questions people ask most often. Every question and every answer is automatically saved, so nothing is lost.
📊 KPI Dashboard
This is the “morning coffee” page — a live, numbers-first view of the entire BGV pipeline: total requests, how many are cleared, how many are pending, and how many have a major discrepancy. It also shows a status breakdown, how long cases have been open (aging buckets), how each vendor is performing on turnaround time, and — critically — a live list of every case currently breaching its SLA.
At the bottom sits the Priority Queue: a ranked list of exactly which candidates need attention today, downloadable as a CSV for anyone who wants to share it further.
👤 Candidate 360
Search for any candidate by name or ID, and this page pulls together everything known about them into one screen: overall status, an approval-readiness badge, a risk score, the assigned vendor and vendor contact, a check-by-check breakdown (education, employment, address, criminal, identity), a dated timeline of everything that’s happened on the case, and — importantly — a plain-English explanation of why the system is recommending “Ready,” “Caution,” “Needs Review,” or “Escalate.” This isn’t a black-box score; every recommendation comes with the specific reasons behind it, so HR can trust it and defend the decision if asked.
From here, HR can download a one-page PDF report or email it directly to a hiring manager or stakeholder.
🕘 History
Every past conversation from the Chat page, tied to the logged-in user’s email, searchable by keyword, newest first. Click “Open” on any past conversation and it reloads right back into Chat so the person can keep going from where they left off.
⚙️ Settings
Users can update their name, role, and email, switch between light and dark theme, and — importantly for trust and transparency — see exactly which AI model is currently answering their questions, and confirm that the system is running in read-only mode.
About
This section explains what each page is about and what BGVerifyIQ stands for.
Dark Mode
What’s happening behind the scenes
For the developers and technical stakeholders reading this, here’s a quick look at how the current version is built, and why each piece exists.
db.py — handles the connection to the PostgreSQL database. It reads connection details from environment variables (so nothing sensitive is hard-coded), keeps one reusable connection pool for performance, and includes a small but important safety function: is_read_only_sql(). This function checks every single query before it's allowed to run, and blocks anything that isn't a plain SELECT. It's the guardrail that makes it safe to let an AI generate SQL on the fly — even if the AI ever tried to write something destructive, this layer would refuse it.
llm.py — the AI layer that turns a plain-English question into a safe SQL query, and turns raw query results back into a clear, professional summary. It's built so that if one AI provider is slow or down, it automatically falls back to a second one — so the app doesn't just stop working during a demo or a busy morning. It also carries strict rules about how to match candidate names and IDs (using flexible partial matching instead of exact matches, since people rarely type a name or ID perfectly), which is a big part of why the Chat page actually finds what users are looking for instead of returning "no results."
pdf_report.py — generates the one-page Candidate 360 PDF on demand, entirely in memory, with careful handling so that special characters (like smart quotes or long names) never break the PDF layout.
mailer.py — sends the PDF report directly to a stakeholder's inbox. Worth noting: this file also tells a useful real-world lesson. It was originally built using standard SMTP email sending, which worked perfectly on a local machine, but failed once deployed to a cloud platform — because most cloud hosting providers block outbound SMTP traffic to prevent spam abuse. The fix was to switch to a transactional email API (Brevo) that works over regular HTTPS, which is never blocked. It's a small example of the kind of real infrastructure problem that only shows up once you actually deploy something.
The data layer — a clean PostgreSQL schema (bgv) with tables for requests, checks, education, and employment history, plus three pre-built views (v_candidate_360, v_sla_breaches, v_vendor_performance) that do the heavy lifting of joining and aggregating data. The AI is instructed to always prefer these views over writing its own joins — which keeps its answers consistent and correct.
Try it yourself
A live version of BGVerifyIQ is deployed and ready to explore:
Feel free to click through every page — Chat, KPI Dashboard, Candidate 360, History, and Settings — with sample data already loaded, so you can see exactly how it behaves before considering it for your own team.
From prototype to enterprise: what a real rollout looks like
What’s described above is a working, functional prototype — and a genuinely useful one. But there’s an honest and important distinction between “a tool that solves the problem well for a demo or a small team” and “a tool that’s ready to run background verification for thousands of employees across an entire organization.” Here’s what that jump actually involves.
A production-grade frontend
The current interface is built using Streamlit, which is excellent for proving out an idea fast. For an organization-wide rollout, this would typically move to a proper frontend framework — Angular, React, or similar — giving finer control over performance, accessibility, custom branding, and integration with existing internal design systems.
A real backend, with security built in from day one
An enterprise version needs a proper backend service layer, not just a script talking to a database. That means:
Authentication — logging in through the company’s existing identity provider (SSO/SAML/Azure AD), not a name-and-email form.
Authorization — making sure a regional HR analyst can only see their region’s candidates, while a compliance officer might see everything, and a vendor SPOC sees only their own cases. Not everyone should see everyone’s data. Basically Role Based Access Control, data masking policies should be enabled. [We will discuss both RBAC and Data Masking in snowflake in another article]
Data security — encryption of data at rest and in transit, strict handling of personally identifiable information (PII), and audit logs of who viewed or changed what, and when.
Proper exception handling — every failure (a database timeout, an AI provider being slow, a malformed input) should fail gracefully with a clear message, never a broken page.
Testing — automated tests for the business rules (like the risk-scoring and readiness logic), so a future code change can’t silently break how a candidate gets flagged.
A feedback mechanism — a simple way for HR users to flag when an AI-generated answer was wrong or unhelpful, so the system keeps improving based on real usage instead of guesswork.
Using AI models your organization already trusts and governs
This is one of the most important points for any organization considering this seriously.
The current prototype uses free, hosted, general-purpose AI models (Groq’s Llama model, and Google’s Gemini, as a backup). These are great for building and proving out an idea quickly — but they were not built or contracted for handling real, sensitive employee data such as names, ID numbers, addresses, and background check outcomes. An organization should not send real employee records to a public, general-purpose AI API unless that API is specifically covered by the company’s data processing agreements and security review.
The right approach for a real deployment is to use whatever AI platform your organization has already vetted and governs — most companies today are standardized on either Snowflake or Databricks for their data warehouse, and both now offer their own governed AI agents:
- If your organization’s data lives in Snowflake, you can use Snowflake Cortex Agents to run directly on your existing tables and views — the exact same bgv schema and views shown above would work almost as-is. The AI never leaves Snowflake's security boundary, meaning your data doesn't get sent to an outside company's servers at all.
- If your organization uses Databricks, the same idea applies with Databricks’ Mosaic AI agents running on your Lakehouse tables.
Beyond just being safer, these governed platforms typically unlock more capability too — automatically generating charts, producing longer comparative analyses (“compare this quarter’s vendor turnaround to last quarter”), and integrating with the rest of your company’s existing data and security tooling, rather than living as a separate, isolated app.
In short: build and prove the idea with free/open tools first (as I did here), then swap in your organization’s approved, governed AI platform before any real employee data touches it.
Additional functionality worth adding
Once the security and governance foundation is in place, a few natural next features come to mind:
- A CRUD page to approve or update candidate status directly from the app — instead of just viewing data, an authorized HR user could mark a candidate as approved, add a remark, or update a case status, with that change written straight back to the source system, fully audit-logged.
- Notifications — automatic alerts (email, Slack, Teams) the moment a case breaches SLA or a suspect flag appears, instead of HR having to go looking for it.
- Integration with the HRMS/ATS — so a “Ready” status in BGVerifyIQ can automatically trigger the next onboarding step, instead of someone manually copying that status elsewhere.
- Feedback and continuous improvement loop — letting users rate AI answers, which helps refine the system over time.
Why an AI agent at all — and why it matters even more on mobile
It’s worth pausing on this, because “just add an AI chatbot” can sound like a trend rather than a real solution. Here’s the actual problem an agent solves.
Traditionally, if an HR analyst wanted to answer a slightly unusual question — “how many campus hires are stuck with a discrepancy this month?” — they had one of two options: ask someone technical to write a query for them, or manually filter and cross-reference spreadsheets by hand. Both are slow, and both mean the person asking the question depends on someone else, or on their own patience with Excel.
An AI agent removes that dependency. It lets someone simply ask, in their own words, and get a trustworthy, data-backed answer in seconds — without needing to know what a database even is. That’s the real value: it turns “I need to go find someone who can pull this” into “I just asked, and I have my answer.”
This matters even more on mobile. A dashboard with charts and tables is genuinely hard to use well on a small phone screen — things get cramped, and scrolling through filters is painful. A chat interface, on the other hand, is something almost everyone is already completely comfortable with, because it looks and feels exactly like every messaging app they already use. On a phone, “just type your question” is a far better experience than “pinch and zoom into a dashboard.” This is a big part of why the agent and the dashboard are built as complementary tools rather than the dashboard being the only option — mobile users, in particular, benefit enormously from being able to just ask.
What this actually solves — the short version
For organization leaders and executives, here’s the summary:
- Saves time — no more logging into multiple vendor portals or manually cross-referencing spreadsheets to answer a simple status question.
- Faster approvals — a clear, explainable readiness badge tells HR exactly who’s ready to move forward, and why, without second-guessing.
- Fewer surprises — SLA breaches and risk flags are surfaced automatically and immediately, instead of being discovered weeks later.
- Less repetitive manual work — one-click PDF reports and direct email delivery replace manually compiling updates for hiring managers.
- Better decisions, not just faster reports — the KPI dashboard turns raw data into visible bottlenecks and vendor performance trends that leadership can actually act on.
- A tool people will actually use — because it meets people where they already are, whether that’s a quick chat question on a phone or a full dashboard review on a desktop.
And to be clear about where this stands today: this is proof that the idea works, built on real, functioning logic — the business rules, the read-only safety design, the recommendation logic — none of that is a mockup. What comes next, for an organization ready to roll this out at scale, is wrapping that same proven logic in enterprise-grade security, governance, and infrastructure — using AI models the organization already trusts with its data, not a public API.
The underlying idea, though, doesn’t change: give HR one place to ask, one place to see, and one place to decide — instead of five different tools that don’t talk to each other.
BGVerifyIQ assists decisions — final approval always rests with the HR team.
Disclaimer
BGVerifyIQ is a demonstration project created to showcase how AI can streamline and improve the background verification process. All data, candidate names, organizations, vendors, and background verification records shown in the application are entirely fictional and generated for demonstration purposes. No real employee, customer, or organizational data has been used at any stage of development, testing, screenshots, or deployment.
The application is built on a carefully designed sample dataset that simulates realistic background verification scenarios while ensuring privacy and confidentiality.
If you have questions about the architecture, implementation, AI workflow, or would like to discuss how a similar solution could be built for your organization, I’d be happy to connect. Feel free to reach out through LinkedIn or leave a comment on this article, and I’ll do my best to help.
