TransformIQ — AI-Assisted ERP Migration (Gemini + Genkit)

AI-assisted classification and entity matching for SAP ECC to S/4HANA/Ariba data migrations — Gemini suggests, a human always decides. Built with Genkit, live on Google Cloud Run.

Comment

Eligibility & Disclosure (Submission Period: Aug 3–31, 2026)

TransformIQ's underlying platform (project scaffolding, deterministic classification, entity-matching, and the governance rules layer) was built in earlier development sprints that predate this hackathon's submission period. The work actually submitted for the All Things Agentic Hackathon is Sprint 5, built during the Aug 3–31, 2026 submission period (work began mid-August 2026): two new, real Gemini/Genkit-powered AI features layered onto that existing platform — AI-assisted semantic type resolution and AI-assisted entity match adjudication. We're disclosing this pre-existing foundation per the contest's "New Projects Only" rule and ask judges to evaluate the submission on the two AI features and their governance integration, which are the newly-created work.

Inspiration

Industry-cited estimates put data migration as the cause of roughly 83% of ERP/SAP migration projects running over budget or schedule — not the application logic, the data. Existing tools either automate too aggressively (silently "fixing" master data with no audit trail) or don't automate at all (manual spreadsheet mapping by a consultant, one column at a time). We wanted a platform where AI does the tedious classification and matching work, but every AI output is a recommendation a human reviews and approves — never a silent write to production master data.

What it does

TransformIQ ingests legacy procurement data (Business Partner, Supplier, Material, Category, Contract records — CSV/XLSX today, connector framework designed for direct source-system integration later), profiles it across five real quality dimensions, resolves duplicate entities with a confidence/evidence model, and validates it against a customer-approved S/4HANA/Ariba target configuration before anything is considered "migration ready." Every step produces an immutable, append-only audit trail: what changed, who approved it, which rule or AI model produced the recommendation. The scope is deliberately narrow — SAP ECC Procurement → S/4HANA Business Partner + Ariba Supplier migration — not a claim to cover every ERP migration path, but the domain this platform actually understands and can defend.

For this hackathon we built and shipped two real, working slices of the platform's AI layer — both named explicitly in our own AGENTS.md governance manual's AI scope ("classification" and "entity resolution"), same architecture, same guardrails, applied to two different judgment calls:

  1. AI-assisted semantic type resolution. When the deterministic semantic-type classifier can't confidently tell what a column represents (is this a tax ID? an email? a phone number?), the profiling pipeline calls Gemini 3.6 Flash through Genkit (a Google Agent Framework) for a second opinion — surfaced in the UI as a clearly labeled, unapplied suggestion with a confidence score and reasoning, never silently written over the deterministic result. No raw personal, tax, or banking data is ever sent to the model — only a structural "shape" of the sample values (letters/digits generalized, punctuation kept) plus the column name.
  2. AI-assisted entity match adjudication. When our deterministic fuzzy duplicate-matcher (Postgres trigram similarity on name/address) finds a candidate pair of Business Partner records whose confidence lands in a genuinely ambiguous band, the same Gemini/Genkit integration gives a second opinion — merge, keep separate, or uncertain, with reasoning — surfaced next to (never inside) the governed decision field a steward alone still controls.

Verified against the live deployment on a 20-record test batch: the matcher found 8 duplicate candidates — 4 resolved by exact identifier match, 3 resolved by a real Gemini call in the genuinely ambiguous confidence band (all three correctly recommending merge at 95% AI confidence), and 1 left untouched by AI because the deterministic signal alone (93%) was already strong enough — the cost-ascending routing rule working exactly as designed, not just in theory.

How we built it

  • Backend: Node/TypeScript, Express, Postgres 16 (Kysely, not an ORM with a native-binary dependency), row-level security per tenant, an append-only audit-event table.
  • AI layer (new): Genkit + @genkit-ai/google-genai's googleAI plugin, calling Gemini via the public Gemini API with a Zod-validated structured output schema — a malformed or hallucinated response degrades to "no suggestion," never a bad write. One shared client construction point, two independent callers, each gated by its own cost-ascending routing rule so Gemini is only ever reached for genuine ambiguity a cheaper method already tried and failed to resolve.
  • Google Cloud: Cloud Run hosts the backend and frontend; Secret Manager holds the Gemini API key (never in code or config); Terraform defines Cloud SQL, GCS, Pub/Sub, and Artifact Registry for the rest of the platform's infrastructure.
  • Frontend: React, with a Data Profile screen and an Entity Resolution screen that each surface the AI suggestion as a distinct, hover-explainable badge next to (never inside) the governed field.
  • Governance, built in from Sprint 1, not bolted on for the hackathon: an AGENTS.md operating manual encodes 17 hard "Do-Not-Do" rules (never let AI silently modify raw data, never treat confidence as authorization, never auto-merge entities, never bypass a blocking validation rule, etc.) that both human and AI contributors are held to.

Challenges we ran into

Getting real second-opinion value out of an LLM call without becoming the thing we didn't want to build — a system where "the AI said so" quietly becomes authoritative. The confidence-policy and audit-trail work (tracking exactly which model/version produced every suggestion, keeping it in a separate column from the governed value) took longer than the API call itself. We also didn't have a real GCP project with billing available for most of development, so the integration was built and tested end-to-end against Gemini's API-key auth path and a fully mocked test suite first, with the Cloud Run deployment validated separately once real GCP access was available.

Accomplishments that we're proud of

A four-sprint foundation (real Postgres-backed ingestion, profiling, entity resolution with a confidence model and an unauthorized-auto-merge guardrail, 168 passing tests, gated in CI on every push) that both AI features had to fit into rather than get built around — and a governance model rigorous enough that "should this be auto-applied?" already had a documented, defensible answer for the second feature (entity match adjudication) before we wrote a line of its code, simply by reusing the same answer we'd already written down for the first.

What we learned

That the hard part of "agentic" enterprise software isn't calling the model — it's deciding, in writing, before you call it, exactly what the model is and isn't allowed to influence.

What's next for TransformIQ

Extending the same AI-assisted, human-reviewed pattern to target-field mapping suggestions (Mapping Studio) — scoped in the existing roadmap, designed to reuse this same Genkit/Gemini integration point rather than a new one. On entity resolution specifically: we've since built and deployed the embeddings-based candidate-discovery pass this section originally described as "next" — it now runs live, calling gemini-embedding-2 to catch a genuinely dissimilar-looking duplicate (e.g. a DBA name with no textual overlap to the legal name) that the trigram matcher structurally can't surface as a candidate. We calibrated it against 6 real measured pairs rather than guessing, and found a genuinely useful, honest limitation: name-only semantic similarity doesn't cleanly separate every true duplicate from every unrelated company — one true duplicate scored lower than an unrelated pair in our test. The current threshold catches the clearer case and knowingly still misses the harder one — closing that gap for good is the real next step, and it needs a second corroborating signal (like matching address/location), not just a better number.

Known limitations

A few things worth stating plainly: a "merge" decision here is recorded and audited but not yet executed — no code in this repo rewrites foreign keys or collapses records, that's scoped as later work. Login uses a dev-token stand-in rather than real SSO, not a production auth path. Entity resolution covers Business Partners and Suppliers only — no Material entity model exists yet in this repo. And the new embeddings-based duplicate discovery is real but incomplete — calibrated against measured data, it still won't catch every semantically related pair, since name-only similarity alone doesn't cleanly separate every true duplicate from every unrelated company.

Try it live

Sign in at the live app above with:

  • Tenant ID: aa58a1b4-8c5c-4de8-ae69-1a4879742777
  • Email: demo@transformiq.example
  • Role: STEWARD

This is a dev-token stand-in for login, not real SSO — the role is client-asserted, not server-verified yet — so treat it as a demo environment, not a security boundary: the seeded data is synthetic, and state is shared across everyone trying the link (if someone else already ran the Migration Readiness Auto-fix before you, the numbers you see reflect that). We use STEWARD here deliberately rather than ADMIN — it's enough to explore Data Profile, Entity Resolution, and Migration Readiness (including Auto-fix) without handing a public link admin-level write access.

Built With

Share this project:

Updates

Submission history