How We Built DeTLeng ProofSQL.

Three systems were good. One coherent system would be better.

DeTLeng originally had three separate repositories: a case-study website, a FastAPI/OpenAI backend, and BigQuery MCP analytics tools. Keeping these pieces aligned increased operational overhead.

• Integrated 100 approved analytics tools into the unified backend.
• Preserved the existing static website and AI Task cards.
• Verified local tests, GitHub CI and Render deployment before relying on the unified service.

“Our AI answers look great. But who checks the numbers?”

All 100 Task cards could query BigQuery and produce conversational explanations. The project owner then changed the acceptance standard: a polished answer was not enough. Visitors should be able to reproduce its numerical evidence.

• Keep the original AI answer visible.
• Recalculate approved KPIs without another paid BigQuery or OpenAI request on the verification click.
• Show exact differences and data provenance—not automatic green badges.

Two calculation paths. One transparent comparison.

The browser does not run arbitrary visitor SQL. It fetches a fixed, allowlisted query and the required static snapshot tables. It can report MATCH, MISMATCH, PARTIAL or NOT VERIFIABLE based on the numerical evidence available.

Start small. Validate the mathematics. Then ship a pilot.

The processed cs003_olist_analytics layer was exported to a private D: drive. Four compact, column-reduced CSV files powered the initial five-KPI browser pilot.

• Total Revenue, Total Orders and Total Products.
• Average Order Value and On-Time Delivery Rate.
• Snapshot checksum validation, SQL provenance, popup interaction and regression tests.

SELECT ROUND(SUM(total_sale_value), 2) AS total_revenue
FROM fact_sales;

Illustrative unqualified SQL equivalent of the verified revenue calculation; the browser engine runs its approved query file against the snapshot.

Move from a successful demo to a mapped verification platform.

The architecture expanded to 100 approved SQL mappings and a nine-table full-v2 static snapshot. The backend supplied structured evidence for scalar KPIs and multirow reports while protecting private identifiers.

• Run Python and JavaScript regression tests.
• Check the 100 SQL definitions and snapshot manifest.
• Deploy the static site through GitHub Pages and the backend through Render separately.
• Preserve accurate outcomes; 100 mappings never meant 100 automatic MATCH results.

The queries were ready. The buttons were not.

Before an employer demo, the project owner tested beyond the early pilot and found many answers without a Verify button. The missing-button cause was not a missing SQL mapping: the frontend only accepted the old metrics field, while expanded responses could contain only records.

if (evidence && evidence.tool && evidence.metrics &&
    (!tool || evidence.tool === tool)) {

if (evidence && evidence.tool &&
    (evidence.metrics || Array.isArray(evidence.records)) &&
    (!tool || evidence.tool === tool)) {

One targeted edit to chat-widget.js was tested locally, reviewed in a Git diff, committed and retested in production. The backend, snapshots and successful five-KPI pilot did not need to be rebuilt.

What was observed. What was not claimed.

Human project lead: defined goals, directed architecture, managed exports and deployments, demanded independent verification, tested production and discovered the pre-presentation defect.

AI engineering assistant: supported architecture, code, mappings, tests, debugging and documentation. The project owner's decisions and hands-on verification drove acceptance.