Inspiration

For many small and medium-sized companies, serious data analytics still feels like a luxury department: expensive, specialized, and difficult to understand from the outside. I began to wonder why knowing SQL is still treated as the entrance ticket to analytics when AI can already handle much of the mechanical query work. A useful answer may pass through several people before it reaches a decision-maker: someone translates the business question, someone finds the data, someone writes SQL, someone checks the metric, and someone rebuilds the result in BI. The cost is not only payroll. It is also waiting, repeated context transfer, inconsistent definitions, and a growing backlog of questions the business stops asking.

That question became personal when someone mistakenly recommended me for a data analyst position. My background is in qualitative socioeconomic and policy analysis, not numerical analytics. I could have treated the recommendation as a simple mismatch, but instead I became curious and decided to prepare technically. I wanted to build an instrument for the new AI era and test a provocative idea: AI will remove parts of established job descriptions while creating demand for a different kind of specialist - an AI engineer-operator who can configure systems, supervise their work, and remain accountable for the outcome across different departments. I believe that, in responsible hands, AI can break open the old monopoly of narrow specialization. That does not make expertise worthless; it radically changes how expertise is assembled, who can build useful systems, and what the labor market rewards.

My first attempt used OpenClaw with control through Telegram. It was an accessible way to experiment with remote agent operation, but it also showed me what was missing for serious analytics: deterministic workflows, semantic rules, bounded evidence, approval gates, and an audit trail. The experiment became a pet-project challenge, and LangGraph seemed like a much stronger foundation for turning it into a governed system. This project does not use or restore the earlier OpenClaw runtime.

When Codex became more capable and GPT-5.6 arrived, I felt that I could turn the idea into a first working demo MVP much faster than I had expected. Building Melmac-DataAI became a practical test of my own transition: could someone coming from qualitative analysis use modern AI engineering tools to build a serious analytical control plane?

My ambition is to make analytics an operating capability rather than a scarce craft available only to larger companies.

Calculators did not make mathematics irrelevant. They moved value away from manual arithmetic and toward framing the right problem, checking assumptions, and interpreting the result. I believe AI can create a similar shift for SQL and repetitive analytical execution. Models can rapidly retrieve and combine broad technical patterns, while people retain the company context, interpretation, and accountability that those patterns do not provide.

That is why I built Melmac-DataAI around an operator model. One or two accountable people should be able to supervise a customizable analytical system: describe a one-off or recurring Business Case, connect governed data sources, review the proposed Investigation, inspect bounded Evidence, approve the Decision, and eventually route approved outputs into the BI tools the company already uses. Different AI roles can use different model providers, including economical hosted models or company-controlled OpenAI-compatible endpoints, without making one vendor the source of truth.

This is deliberately more ambitious than an analytics copilot. The product is designed for AI to perform most repeatable analytical execution while a much smaller human team sets business intent, resolves ambiguity, approves consequential effects, and owns the final decision. OpenAI models can fit specialized roles inside that governed boundary without becoming the authority for metrics, evidence, or business action.

My planning model estimates a 42-55% nominal steady-state saving for suitable SMBs with repeatable cross-source workloads when the modeled traditional capacity is actually retired or avoided. The 50%+ hypothesis applies to its base and larger scenarios, not every company; transition-period savings can be much lower or even negative. These are targets for paid-pilot validation, not a universal result or a claim proved by the current prototype. The product is designed to remove repetitive handoffs and manual execution, not human business judgment.

What It Does

Melmac-DataAI organizes work around Business Cases rather than chats, dashboards, or agent activity. The deployed demo presents a previously authorized, persisted training execution through a governed path from a business question to a bounded, auditable Evidence Packet:

  1. The Business Case Board shows what needs attention, why it is blocked, what evidence exists, and what should happen next.
  2. The AI Curator preserves a typed, cited Investigation proposal. Confirming it creates scope; it does not silently authorize a query.
  3. A deterministic LangGraph control plane validates the Workplan, semantic contract, source scope, SQL safety, cost ceiling, evidence requirements, and exact effect authority.
  4. The recorded approved warehouse read collected only bounded aggregate evidence. The execution is replay-safe, and the full result table was not persisted.
  5. The Evidence Packet keeps immutable revisions, hashes, provenance, reconciliation, and limitations. It remains validating until the required review exists.
  6. The Audit records every implemented transition so the system cannot quietly turn a proposal into a business fact.

The demo deliberately stops before Human Evidence Review and a business Decision because those authoritative write paths are not yet active in the deployed prototype. BI publication, materialization, autonomous decisions, and background monitoring are also not presented as live. Fresh warehouse and external-model effects remain held during the public demo; it does not rerun BigQuery or a model for presentation.

How I Built It

The architecture separates five kinds of authority that agent demos often collapse:

Models propose.
LangGraph validates.
Warehouse evidence proves.
Humans approve.
Audit remembers.
  • Python, FastAPI, and Pydantic define typed APIs and fail-closed domain contracts.
  • LangGraph is the deterministic control plane for routing, validation, checkpoints, and approval boundaries.
  • PostgreSQL stores durable control-plane state, immutable artifact revisions, and audit history.
  • BigQuery is used through bounded metadata, dry-run, and approval-bound aggregate-read boundaries.
  • Portable semantic contracts define metric, grain, join, source, and governance truth outside any single BI tool.
  • SQLGlot supports deterministic SQL analysis before a warehouse effect is allowed.
  • A bilingual, dependency-light operator console exposes Business Cases, Investigations, Evidence, source health, documentation, model-provider settings, and audit.
  • Provider settings support governed profiles for OpenModel, OpenRouter, direct-compatible, and explicit self-hosted endpoints. Model-role activation remains benchmark- and approval-gated.
  • Codex and GPT-5.6 Sol were used as the engineering control surface for architecture, implementation, independent review, regression design, security reasoning, CI verification, and release hardening. They are not hidden production decision authorities.

The architecture keeps BI downstream. Existing local exporters can produce governed artifacts for targets such as Superset and Metabase, but network publication and BI writes remain disabled in the prototype.

Challenges I Faced

The hardest problem was not generating SQL. It was preserving exact authority while the world changes around an analytical run:

  • a semantic contract or source revision can change after approval;
  • a warehouse request can time out after the provider accepted it;
  • retries can accidentally create a second billable job;
  • model output can be structurally valid but analytically unsupported;
  • UI state can make incomplete evidence look ready;
  • logs, screenshots, and demos can leak data even when the database is protected.

I addressed these as control-plane problems: immutable artifact revisions, deterministic hashes, scope-bound Approvals, effect identities, lease fencing, idempotent replay, explicit ceilings, sanitized audit events, and fail-closed projections. One release repair traced a production read failure to validation across Evidence Packet revisions; the fix added memory and PostgreSQL regressions and was revalidated through local tests, private CI, Railway health/readiness, and a browser walkthrough.

Accomplishments I Am Proud Of

  • A deployed bilingual Business Case supervision console (English/Ukrainian).
  • A governed proposal-to-Investigation path with typed Analytical Workplans.
  • Deterministic semantic, source, SQL-safety, and cost validation.
  • Approval-bound BigQuery aggregate evidence collection with strict row, byte, and time limits.
  • Immutable Evidence Packet history with deterministic hashes and provenance.
  • Replay-safe execution that reuses the same provider job instead of issuing a second query.
  • No persistence of raw result rows or the complete warehouse response.
  • A provider-neutral settings foundation with encrypted, write-only credentials and distinct saved, verified, approved, and active states.
  • A searchable bilingual Documentation Center for operator, administrator, and developer journeys.
  • Release 0.12.14 is deployed, with passing local, private CI, and hosted-Linux isolation checks.

What I Learned

The future of analytics is not "AI answers everything." It is a system in which broad machine capability is constrained by strict rules and strong pipelines.

I also learned that model flexibility matters to smaller companies. SQL authoring, criticism, evidence interpretation, and narrative explanation do not necessarily need the same model. A role-specific portfolio with freedom to choose among LLMs can optimize quality, latency, privacy, and cost, while a provider-neutral boundary prevents an enterprise vendor from owning the analytical truth.

Finally, open-source BI does not remove the hard parts of analytics. Superset, Metabase, and similar tools can make consumption affordable, but source reconciliation, metric ownership, evidence quality, review, and audit still need a control plane.

What's Next

Melmac-DataAI is an actively evolving prototype. After the hackathon submission, a major product focus will be making the handoff from reviewed Evidence to the BI environments companies already operate more useful without weakening approval or audit controls.

  1. Activate typed Human Evidence Review and Decision Brief recording without weakening the current authority chain.
  2. Complete role-specific model benchmarks on hidden, reproducible analytical datasets before any model is promoted into runtime.
  3. Extend the governed source fabric from BigQuery and PostgreSQL to immutable spreadsheets, GA4, and bounded read-only APIs; the architectural boundaries for these sources are already in place.
  4. Add recurring Business Cases with explicit scheduler authority, exception handling, operator-visible monitoring, and a controlled cron mode.
  5. Validate the 50%+ cost-reduction hypothesis through paid pilots that measure cycle time, reviewer correction rate, analyst hours avoided, support burden, and total cost.
  6. Add an approval-bound Local BI Bridge: the control plane prepares a signed export plan, a customer-controlled runner applies it to local or on-premises BI, and an immutable receipt returns to Audit. Enable direct downstream BI publication only after identity, RBAC, and live target reconciliation are complete.

The future I am building toward is not analytics without people. It is analytics made dramatically more accessible to small and medium-sized businesses by replacing unnecessary manual ceremony with a governed operating system. In this model, one accountable operator can configure the system around business rules, supervise its work, and own decisions while AI performs repeatable execution.

That changes the talent model. Demand will not simply disappear from data analysts; it will shift away from manual query production and dashboard assembly toward a new kind of specialist: an AI Analytics Operator or Analytics Systems Engineer - a hybrid of an analytics engineer, AI engineer, governance owner, and business translator. This person does not need to perform every analytical step by hand. They need to customize the system for a company, connect and govern its data, define semantic truth, monitor reliability and cost, resolve ambiguity, and ensure that outputs are safe and useful.

If I get this right, serious analytics can stop being a luxury department. It can become an affordable, continuously improving operating capability for small and medium-sized businesses: one accountable operator supervising a system that can propose broadly, prove narrowly, act only with approval, and remember exactly what happened.

Built With

Share this project:

Updates