Skip to main content

Reviewing translations

Forge's LLM translates views, stored procedures, UDFs, and macros from Teradata / Oracle dialects to BigQuery dialect. The translations are usually correct — but they're not blindly trusted. Every translatable artifact in a wave goes through a review step before it can deploy.

This page covers the review workflow: what you see, what to look for, and what the bounded self-heal loop already did before it reached you.

Goal​

You finish this page with every translation in your wave reviewed and either approved or queued for re-translation.

Prerequisites​

  • A wave with at least one translated artifact. See Creating a migration wave.
  • Familiarity with the source dialect's quirks (Teradata's QUALIFY, Oracle's CONNECT BY, etc.) — translations are usually right but you'll be the judge.

What you see in the review UI​

For each translatable artifact, the review page shows three panes:

1. Source SQL (left)​

The original Teradata or Oracle source. Read-only.

2. Translated SQL (centre)​

The LLM-produced BigQuery SQL. Editable. If a manual edit is more correct than the LLM's, change it here.

3. Self-heal log (right)​

A log of what Forge tried before producing the current translation:

  • The LLM's first attempt.
  • The deploy error BigQuery returned, if it failed.
  • The LLM's revised attempt, with the error fed back as context.
  • Repeat, up to the self-heal retry budget (default 3).

If the artifact reached you in Translated state, the LAST attempt deployed cleanly to a sandbox. The log is the audit trail of what got it there.

If the artifact reached you in Failed state, the self-heal loop exhausted its budget and you have a manual-fix-or-skip choice.

What to check​

The translations that need the closest look:

Stored procedures​

  • Control flow — IF / LOOP / WHILE / EXIT constructs map differently between Teradata, Oracle, and BigQuery. Translations sometimes simplify control flow in ways that change semantics under specific input.
  • Cursor logic — Teradata cursors → BigQuery iteration is non-trivial. Read the translated logic carefully.
  • Exception handling — EXCEPTION WHEN OTHERS doesn't have a direct BigQuery equivalent.

Views​

  • QUALIFY clauses — Teradata uses QUALIFY for window-function filtering; BigQuery supports it natively but translation may rewrite to a subquery.
  • SAMPLE modifiers — different statistical semantics.
  • PARTITION BY and INDEX hints — BigQuery doesn't have indexes; translations usually drop the hints, but verify the rewrite is equivalent without them.

UDFs​

  • Recursive UDFs — BigQuery doesn't support recursion. Self-heal usually flags these as failed.
  • JavaScript UDFs in Oracle (rare) — translated to BigQuery JS UDFs but the runtime quotas are different.

Macros (Teradata)​

  • BigQuery has no direct equivalent. Macros translate to table-valued functions or inline expansions. Verify the chosen pattern matches the macro's actual usage.

Steps​

1. Open the wave​

In your Forge project, open the Waves tab and click into the wave with translations to review.

2. Pick an artifact​

The wave's table lists every artifact with a status. Click any Translated or Failed row.

3. Read the panes​

Source on left, translated in centre, self-heal log on right. The diff between source and translated is also available in a side-by-side view.

4. Approve, edit, or re-translate​

Three buttons at the top of the artifact:

  • Approve — the translation as-shown is what will deploy. Status moves to Approved.
  • Edit & Approve — you've changed the centre pane manually. Same effect as Approve, with the manual version saved.
  • Re-translate — discard the current translation and run the LLM again. Useful if you suspect the LLM had bad context the first time. Counts against the wave's retry budget.

5. Repeat for all artifacts in the wave​

A wave can't move to validation until every artifact in it is approved or explicitly skipped.

Skipping an artifact​

For artifacts that genuinely can't move (recursive UDFs, business-logic dead-ends), click Skip on the artifact. Skipped artifacts:

  • Don't deploy with the wave.
  • Are flagged in the project's outstanding-debt report so they don't get forgotten.
  • Can be added to a later wave with manual reimplementation.

Common issues​

The translation looks plausible but I'm not sure. Click Run validation in the artifact's toolbar. Forge runs the translated artifact against the target sandbox with synthetic inputs and shows the result. Catches simple misses fast.

Self-heal log shows 3 failed attempts but the artifact is in Translated state. The 4th attempt succeeded, so it's now Translated. The history shows the self-heal worked — that's the design.

Editing the translated SQL produces parse errors. The editor validates against BigQuery dialect on save. Read the underlined errors and fix them, or click Reset to LLM to revert.

A teammate already approved an artifact and I disagree. Click Reopen on the artifact (admin or project owner only). It moves back to Translated and either of you can approve a different version.

Validation passes but the deploy still fails. Some failures only surface in deploy, not validation (target permissions, dependent objects in unexpected order). The deploy failure feeds back into self-heal — see Approving and deploying.

See also​

QRYA product of IXEN.