Eight AI products on one knowledge graph. Three in production this year.

Goal: give an emissions analyst one place to go from a refinery's raw sources to a defensible OGMP 2.0 methane submission, with every figure traceable.

I designed and built the front-end of the Distillery workspace: a library of data sources (SCADA historian, LDAR surveys, fuel-gas logs, emission factors, device registers), the Reporter, Profiler and Distiller agents, projects such as an OGMP 2025 submission, running jobs with live progress, and chats that keep their findings. Watch it above.

Tradeoff (Real estate): one workspace for sources, agents, running jobs and saved findings instead of four tools, because the analyst's question spans all four.

Goal: let knowledge engineers see and shape the graph under every product: assets, equipment, measurements and events as linked records, not tables.

I designed and built the KEW front-end. The records view lays out an upstream gas field as a graph: well pads, wellheads, gas meters, equipment, liquids-unloading and blowdown events, gas samples and LDAR surveys, grouped and filterable, with a classes view beside it. Watch it above.

Tradeoff (Breadth vs Depth): one general records-and-classes graph view instead of a bespoke screen per asset type, because the ontology changes faster than screens can.

Goal: show a plant's production, emissions and intensity the way operators think about the plant: by process area, on the ground.

I designed and built the DaaS front-end: the facility on satellite imagery with process areas as polygons, a facility panel with NH₃ produced, CO₂e and emissions intensity for the period in view, scope filters by reporting period, process area and emission source, weekly production and CO₂-capture charts, and CSV export. Watch it above.

Tradeoff (Required vs Optional): map-first, with process areas as the primary filter and charts secondary, because operators reason in plant areas, not tables.

After building Immutably™'s Knowledge Graph technology to create industrial digital twins, we had a powerful insight infrastructure. Energy clients were using it to model entire facilities, but the KG capabilities (ontology mapping, sub-second queries, data provenance) could do so much more.

We spotted the opportunity: EPA's GHGRP emissions data was public but difficult to use. Researchers spent weeks wrangling Excel files, journalists couldn't cite sources, and custom calculations had zero reproducibility. Our KG technology could solve all three problems at once.

I built the OpenEPA POC using Claude to prototype the Q&A interface, connecting it directly to our existing KAG (Knowledge-Augmented Generation) infrastructure. The pilot validated our hypothesis: researchers could ask natural language questions and get cited, verifiable answers from 15 years of EPA data.

In parallel, we built Context AI, a microservice for energy sector client intelligence. Using Vue 3 + TypeScript, I created an AI-powered onboarding flow that extracted company context in 60 seconds instead of 2+ hours. The frontend was built with mock services to unblock development while the backend caught up, saving 3 weeks.

With the POC validated, we built the full OpenEPA platform infrastructure. I designed the EPA data ingestion pipeline with version tracking where every emissions report is timestamped with its EPA source URL and release date. This wasn't just about loading data; it was about creating an audit trail that researchers and journalists could trust.

We integrated ArcadeDB as our Knowledge Graph store, leveraging the same ontology-mapping capabilities we'd built for Immutably™. The result: sub-second queries across 2,800+ facilities and 15 years of emissions history. Researchers could compare facility emissions trends, identify geospatial hotspots, and benchmark Top/Bottom 5 emitters, all with full data provenance showing exactly where each number came from.

Goal / North Star: help energy account execs reach trusted client decisions faster, and give researchers verifiable access to public emissions data. North star: trusted answers delivered per hour of analyst time.

With the EPA data pipeline running, we deployed Context AI on Azure to power the intelligence layer. The challenge was connecting AI models to our Knowledge Graph so they could answer complex emissions queries with full citations. We used Azure OpenAI Service with GPT-4, building a custom integration layer that translated natural-language questions into KG queries and synthesized responses with EPA source attribution. I built the Vue 3 + TypeScript client on top.

The Context AI microservice became the bridge between our KAG infrastructure and both OpenEPA (for emissions Q&A) and the energy sector AE dashboard. For OpenEPA, researchers could ask "Which Texas refineries increased emissions most from 2020-2023?" and get cited answers with EPA report URLs. For the AE dashboard, Context AI analyzed client KG data to generate company intelligence in minutes instead of hours.

Tradeoff (Ship vs Don't-ship): I shipped against a hard trust bar rather than maximizing answer coverage. Anything we couldn't cite, we didn't surface, because the audience (AEs closing deals, researchers, journalists) can't act on a black-box number.

Goal / North Star: make industrial and emissions calculations reproducible and comparable across facilities, so a number can be trusted, audited, and re-run a year later. North star: reproducible calculations adopted in real reporting workflows.

I built the front-end myself, a Nuxt 4 + Pinia + shadcn-vue workspace with a visual calculation-lineage graph and a dataset-binding / join configurator, on a versioned Workspace → Routine → Execution model. The team's backend handles the heavy lifting: Java 21 with a dual API (REST + GraphQL via Netflix DGS), PostgreSQL + Liquibase, Apache Spark 3.5 for distributed materialization, and a property-graph query surface over roughly 484 facilities, 62k equipment, and 10k edges. This one is deterministic, explicitly not an LLM product.

Tradeoff (Invest vs Maintain): I invested in versioning, formula transparency, and audit trails up front rather than shipping a faster one-off calculator. For analytics people stake reports on, reproducibility is the product; a clever but opaque number is a liability.

Calculation lineage (5 calcs · 8 links) with a visual join / dataset-binding configurator, bind a dataset, choose join type, and map columns.

Goal / North Star: make data trustworthy before it reaches a model or a report, without ever exposing the underlying data. North star: datasets shipped with a passing, machine-checkable data contract.

This is the clearest orchestration story. I built the Vue 3 + TypeScript UI over a 7-stage multi-agent pipeline coordinated with DSPy, Planner → Profiler → Baseline Observer → LLM Observer → Reviewer → Summarizer → Report Generator. It auto-generates data contracts (datacontract.com format) plus Python and Scala validation code, and connects to CSV, LakeFS, Delta Lake, Delta Sharing, and REST APIs. The pipeline routes LLM calls through LiteLLM across Azure, OpenAI, Anthropic, and self-hosted Ollama, so the same product runs in the cloud or fully air-gapped. This is what "orchestrated multiple model providers and deployed our own models" looks like in production.

Tradeoff (Required vs Optional): I made privacy a hard requirement: the LLM stages see synthetic samples only, never real data. That caps how much raw context a model gets, but it's exactly what makes the platform usable on regulated and air-gapped EU data, which is the whole point.

Goal: let domain experts author and convert ontologies in the browser, no toolchain, no install, no format lock-in.

I ported it from an existing Flutter app and built the Nuxt 4 + Vue 3 UI: a Vue Flow + dagre graph layout, a CodeMirror code view, and multiple view modes (diagram, tree, split, code). It imports and exports four ontology formats entirely client-side, LinkML YAML, OWL RDF/XML, CLCE, and OSE, on the Context Labs UI library (shadcn-vue, 80+ components).

Tradeoff (Breadth vs Depth): I prioritized format breadth and a frictionless browser experience over deep single-format tooling, because the real adoption blocker was that experts couldn't move between formats without engineering help.

Goal / North Star: turn "people use an AI tool" into "the org ships AI-assisted code to one standard." North star: AI-assisted changes that meet the quality bar without rework.

I helped build a private Claude Code plugin marketplace for our dev teams, on a Code Completeness Model (CCM), a reusable reasoning framework covering 10 quality aspects (design, error handling, security, testing, and more) across project, module, and function scope. Five skills, CCM, TypeScript, Vue, Nuxt, shadcn-vue, totaling roughly 22,000 lines of guidance across ~140 files. It auto-enables for teammates via project settings, so AI-assisted code follows org standards by default, on Anthropic Claude.

Tradeoff (Invest vs Maintain): I invested in one shared, versioned framework rather than letting each team prompt its own way. The upfront authoring cost buys consistency and review leverage that ad-hoc prompting can't, and it scales to new hires automatically. Capability is easy; adoption is the product.

As we prepared for OpenEPA's public launch, we formalized our team structure. We established an R&D office in Amsterdam with a small, focused team tracking work through a Kanban board and running bi-weekly retros. This wasn't just about process but about culture. We transitioned from an Engineering-led approach (build features, ship code) to Product-led (solve user problems, measure impact).

This transition actually started earlier with my work on the Immutably™ platform, where I shifted the company from feature-driven development to user-research-driven product strategy. With OpenEPA, Context AI, and Calculation Editor, we applied those same lessons: validate with users, ship MVPs fast, iterate based on feedback, and measure everything.