Ihsan Wanda
Data Platform Architect · Analytics Engineer
I build the layer that makes a data platform answer questions in its own language — semantic models, validated metric definitions, and self-documenting warehouses. Underneath that, I ship end-to-end dbt pipelines and the agent systems that work reliably around them. Daily, that means reconciling messy commercial data until the numbers stop lying.
A note on the numbers on this page. Every figure below comes from a file I can point you to — a test manifest, a run log, a validation report. Where something failed or is still open, I say so rather than rounding it away. That habit is the same one that shapes the work.
01Platform architecture
The hardest problem in analytics isn't storage or compute. It's that nobody can say what the numbers mean — so every question routes through one person, and every metric is re-derived from scratch.
I built a semantic layer over a production platform: 118 tables and
65 pipelines distilled into a 35-concept graph (70 typed relations)
and a 135-metric business tree, then compiled into a single offline HTML file that
opens from file:// with no server and no runtime dependencies.

The machine may propose; the domain owner disposes. Every AI-authored artifact is validated against source before it's trusted, and an owner can reject it. Of 135 proposed metrics, 128 were approved, 6 failed validation, and 1 was rejected by its owner — a metric tree with a 100% approval rate would mean nobody was checking.
Verified from the repository's validation report · owner decisions recorded separately and always take precedence
02Analytics engineering, end to end
Two public pipelines, both live, both with CI enforcing every test.
palm-analytics-dbt
Four keyless data sources → a Kimball star schema across 23 models
(staging → intermediate → marts), with SCD2 snapshots,
model contracts, custom macros, and 99 passing tests in CI. It serves an
interactive dashboard where an estate manager decides the day's operations.

99 of 99 tests pass in CI · all four sources are public and keyless
developer-marketing-measurement-dbt
Marketing measurement where ad platforms over-claim conversions by hundreds of percent. Attribution triangulation: Multi-Touch Attribution + Media Mix Modeling (adstock & Hill saturation) + incrementality testing (geo-lift, holdouts), reconciled into one tested semantic layer. 15 models, 19 passing tests.

19 of 19 tests pass · campaign and PLG telemetry is synthetic; the modelling layer is real
03Messy business problems, daily
Most real analytics work is not greenfield. It's three systems that disagree, and a number somebody trusts.
CRM sales reconciliation — a manual process, rebuilt as a verifiable pipeline
Replaced a team's manual reconciliation with a pipeline that unified three separate systems, matching 18,537 orders (98.5%). Doing so surfaced defects the manual process had been silently absorbing:
| Defect surfaced | Scale | Status |
|---|---|---|
| Records double-counted across two systems | 12 records, 0.06% overstatement | fixed |
| Partially-paid records counted at full value | 2.1% overstatement | fixed |
| Cancelled records with payment retained | 87 records | escalated |
| Shipping counted as revenue | 926 records | escalated |
| A "trusted" headline figure that moved 92% in one day | flagship metric | escalated |
Each defect ships with a runnable verification query, so any claim can be re-tested instead of taken on trust. The point of the migration wasn't saving hours — it was that the numbers became verifiable.
Match rate measured on the reconciliation run · 4 of 5 defect classes were still open with the owning team at the time of writing
04Research & agent systems
Research that turned into working systems, with published benchmarks.
arc-cua — browser harness & grounded document extraction
An agent sees a page as a token-budgeted accessibility tree with [#N] action
indices, and acts through verified actions. Built on it, ARC Index extracts
each field from a document with an evidence quote and citation, and refuses any value
it cannot prove at the cited row — then batch-fills the form and returns an audit
receipt.
| Measured on live cloud browsers | Baseline | This work |
|---|---|---|
| Task success, same model head-to-head | 21 / 24 | 24 / 24 |
| Input tokens across 24 runs | 458,546 | 122,034 · 3.8× fewer |
| Input tokens per document appeal | 26,955 | 1,209 · 22× fewer |
| Cost per appeal | $0.02575 | $0.00305 · 8.4× cheaper |
| Wall time per appeal | 89 s | 11.4 s · 7.8× faster |
| Wrong values let through, of 60 fields | 0 | 0 · equal accuracy |
Same model on both sides. Raw per-run JSON is committed, and the measurement method is written up in the repository.
Runs recorded 2026-09-27 / 09-29 · token counts estimated from characters on both sides, so the comparison holds
sawit-field-crm
A field CRM app for palm-oil enumerators — Streamlit + Bitable API, 53 passing pytest tests. Building the tools the team actually uses is part of the job.
53 tests pass · single-team deployment, not a multi-tenant product
05How I work with AI
Not autopilot — I build the contracts that make it safe, and the reasoning lives in the repo.
- 8 repos carry machine-readable operating contracts (
CLAUDE.md/AGENTS.md) specifying commands, authority, and production risk — including which target writes to real production, and which source wins when two disagree. - 15 ADRs in the commercial ETL record why a decision was made, not just what was built.
- Validators with teeth: every AI-authored artifact is checked against source before it's trusted, and a human owner can reject it.
- Measured post-mortems encoded as rules — a working agreement written because one avoidable mistake cost three hours, with the hours recorded.
- AI co-authorship is disclosed in git history, not hidden.
The through-line: ungrounded data shouldn't be trusted. In analytics that's a metric with no source; in agent systems it's a form field with no evidence. Both projects above enforce the same rule — propose, validate, let a human dispose.
06How I got here
One method, applied three times: learn by building, let real users correct you, then erase the bottleneck you just found.
From industrial engineering → data → agentic AI
I started in industrial engineering, where the job was never to theorize — it was to build something, watch it fail under real conditions, and fix the flow. That's how I moved into data analytics about six years ago, and it's the same reason I'm moving into AI now.
My first AI-assisted build was a team donation app. The problem was ordinary and I'd seen it repeat: contributions announced in a chat group, transfer screenshots scattered across private threads, one person manually reconciling the mess before every deadline. The transparency was fine — what was missing was a clear flow. I volunteered to build it, shipped it, then ran it against real colleagues: ask for feedback, watch where the flow breaks, ship again.
That loop taught me more than any course, and it also exposed my own gap — I was copying code into a chat and pasting it back without understanding Git or CI/CD. So I rebuilt the loop around agentic coding, which let me read a pipeline instead of guessing at it. The projects above are the result of that shift.
129 of 129 tests pass · Supabase + Cloudflare Pages · donor sign-up, equal-split or custom amounts, combined payments, receipt upload, PIC verification, refunds on overshoot
07Also
- proofscout — trust-bound market-intelligence scanner: fail-closed approvals, immutable evidence, offline test suite. Repository
- orakuru-bonding-curve-analytics — on-chain bonding-curve suite (dbt/DuckDB, Dune V2). Repository
- analytics-architecture-decisions — ADRs on warehouse cost-optimization and materialization. Repository
- Contributed 8 merged fixes to upstream nakama.