AI Legacy Transmuter

MigrationOnboardingStaging Branch

Roadmap Planned · not yet usable · advanced onboarding pipeline; verify availability before relying on it

What it is

The AI Legacy Transmuter is an onboarding pipeline that connects to a running source database, reads its schema and stored procedures, and produces an AetheriusDB target — not a naive one-to-one copy, but a rewrite. Tables are grouped into natural layouts, sequences become lock-free id generators, legacy CHECK constraints can be upgraded into AI quality constraints, and stored procedures are translated into WASM compute cells.

Everything lands on a staging branch — a fully queryable snapshot you can validate with your own queries before committing to cutover.

flowchart LR
  classDef src fill:#1f2640,stroke:#9ca3af,color:#e8eaf0
  classDef step fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
  classDef out fill:#1f2640,stroke:#4ade80,color:#4ade80

  LEG[(Legacy DB<br/>Postgres / Oracle / SQL Server)]:::src
  LEG --> SCH[Read schema + query patterns]:::step
  SCH --> MAP[Group tables into layouts]:::step
  LEG --> PRC[Extract procedures]:::step
  PRC --> XLT[Translate to WASM cells]:::step
  MAP --> ST[(Staging branch)]:::out
  XLT --> ST

Why it matters

A migration is where most projects lose weeks: schemas get copied one-to-one, stored procedures get rewritten by hand, and cutover is a nervous big-bang. The Transmuter does the rewrite for you — grouping tables into natural layouts, turning sequences into lock-free id generators, translating procedures into compute cells — and lands it all on a staging branch you validate against your own queries before you commit to anything.

A rewrite, not a dumb copy — the target is shaped for AetheriusDB, not a mirror of the legacy layout.
Validate before cutover — everything arrives on a queryable branch, so you test on real data first; there’s no big-bang switch.
Logic comes along — stored procedures and CHECK constraints are migrated into cells and AI quality constraints, not left behind.

How you use it

Point the transmuter at your legacy database, name a staging branch, and let it run as a dry-run. When you’re happy with the result, promote.

-- Kick off the dry-run: reads schema + procedures, writes a staging branch.
CALL aether_transmute(
  source        => 'postgresql://user:pass@legacy.host:5432/billing',
  staging       => 'billing_staging',
  upgrade_checks_to_ai => TRUE,
  translate_procedures => TRUE
);

-- Inspect the decisions and confidence scores; review low-confidence first.
SELECT source_object, target_object, kind, confidence, rationale
FROM _sys_transmute_log
WHERE staging_branch = 'billing_staging'
ORDER BY confidence ASC;

-- Run your own validation queries against the staging branch.
SELECT COUNT(*) FROM billing_staging.invoices;

-- Happy? Promote the staging branch into the live namespace.
PROMOTE BRANCH billing_staging TO billing;

The transmute log is the artifact you hand to a reviewer: every translated procedure carries a confidence score, and low-confidence ones deserve human eyes before promotion.

Key concepts

Concept	What it means
Staging branch	An isolated, queryable namespace holding the output until you promote it.
Procedure translation	Converting PL/SQL, PL/pgSQL, or T-SQL bodies into WASM compute cells.
Confidence score	A 0–1 number on each translation; low scores flag items needing review.

Notes & caveats

AI Quality Constraints →

What legacy CHECKs are upgraded into.

Cognitive Kernel →

The in-process model runtime behind translation.

Multimodal Fabric →

Companion pipeline for media-heavy schemas.

Compute →

The WASM cell model procedures translate into.