JarvisX Documentation

JarvisX is an AI-powered code modernization platform built for enterprise migrations. It automatically translates legacy database views, stored procedures, analytical queries, ETL pipelines, and scripts into modern target-native dialects with semantic parity checks. Unlike simple LLM wrappers, JarvisX employs a strict 13-layer quality engine combining deterministic parsing with context-isolated LLM micro-prompts.

1. Sign In: Connect securely via Google SSO or magic-link fallback. Your personal organization is auto-minted immediately. 2. Choose Dialect Target: Specify your legacy source (e.g. Teradata, Oracle, Informatica) and target cloud (BigQuery, Snowflake, Databricks). 3. Upload Source: ZIP your directories or authorize the JarvisX GitHub App to select active repositories. 4. Quality Inspection: Run the 13-layer pipeline to generate AST syntax, semantic matching scores, and human-in-the-loop review flags. 5. Download: Close the tab; we will email you when the compilation is ready, or merge the output Pull Request directly on GitHub.

Anyone can convert SQL for free with no sign-up at gojarvisx.ai/playground. Each machine gets 5 lifetime conversions, tracked by IP + browser cookie so the allowance can't be trivially reset. The playground runs the deterministic engine only — rule-based rewrites plus sqlglot AST transpilation (no AI, no LLM cost) — so results are exact and repeatable across the sqlglot-supported dialects (Teradata, Oracle, SQL Server, MySQL, PostgreSQL, Hive, Spark, Redshift, Snowflake, BigQuery, Databricks). Code and ETL-workflow conversions require AI, so those prompt you to sign in. Signing in is free (no credit card) and unlocks the full 13-layer AI engine, code + workflow conversion, and full-project migrations. Logged-in accounts keep their own separate free Try Now / plan allowances — the 5 no-login conversions are strictly for anonymous visitors on that machine.

The Migration Readiness Analyzer (gojarvisx.ai/analyze) scans any public GitHub repository and returns a readiness report — file breakdown, dialect detection, risk findings, and a plan recommendation. Sign-in is required. Free repository scans are capped per account across your tenure: Free plan = 50 successful scans, paid plans (Team / Business / Scale) = 100 scans, Enterprise = 500 scans. Only scans that produce an actual report count toward the limit (failed or invalid-URL attempts do not). When you reach the cap, upgrade your plan to raise it. Your live remaining/total scan counter is shown right on the Analyze page.

An Organization is your team container for bills, logs, SSO, and workspaces. You do not need to create one manually — your personal organization is created automatically on your first action. Workspaces are isolated migration projects linked to a specific code repository (you can attach multiple ad-hoc batches and GitHub-imported codebases to one workspace). Submissions are lightweight one-off tries (like pastes on the Live Converter or ad-hoc batch ZIPs) that do not generate invoice templates. Collaborative roles include Owner, Admin, Reviewer, Member, and Viewer.

Layer 00: sqlglot deterministic transpilation (15 dialects). Layer 01: Pre-LLM deterministic rewrites (23 rules including NVL, QUALIFY, SEL expansion). Layer 02: Complexity-adaptive prompting. Layer 03: Feature detection cards. Layer 04: 121 pair-specific conversion cards. Layer 05: RAG HyDE + RRF reranking vector search. Layer 06: Advanced LLM agent translation. Layer 07: Post-LLM deterministic updates. Layer 08-09: Syntax & category validations. Layer 10: Auto-repair & reconversion (capped LLM fixes for failed/empty outputs). Layer 11: Live execution validation (DuckDB) — the converted SQL is actually run against generated sample data and its result rows are diffed against the source, proving correctness rather than just syntax; on failure it self-repairs with the runtime error as a hint and re-validates. Credential-free; covers all 44 source-to-target SQL pairs. Layer 12: Sampled semantic scoring + confidence scoring and audit triggers.

Generate personal access tokens from the API Tokens panel. These tokens are hashed at rest. Use the JarvisX CLI to trigger batch migrations from your CI/CD pipelines.

curl -X POST https://gojarvisx.ai/api/v1/batch \
  -H "Authorization: Bearer <your_token>" \
  -F "file=@workload.zip" \
  -F "source_dialect=teradata" \
  -F "target_dialect=bigquery"

JarvisX is a discoverable Agent2Agent (A2A) agent, so an external orchestrator — Google ADK, Vertex AI Agent Engine, LangGraph, or any A2A-compatible agent — can discover and call JarvisX as a governed tool. The caller sees only the published skills; the internal pair-cards, prompts, and AI pipeline stay behind the boundary. Governance stays intact: no LLM decides pass/fail, and humans still approve real cutovers. Note: A2A is feature-flagged. When enabled, the compute endpoint requires a bearer token. Discovery: GET https://gojarvisx.ai/.well-known/agent.json returns the A2A Agent Card — the agent name, url, version, security scheme, and the list of skills. Compute: POST https://gojarvisx.ai/a2a is a JSON-RPC 2.0 endpoint. The only supported method is "message/send". Authenticate with a bearer token sent as the header Authorization: Bearer <token>. The standard credential is a platform API token (jvx_…) that you mint from the API Tokens panel — so every A2A call is attributed and billed to a real account, and can be revoked. (Operators may optionally configure a single shared A2A key for partner/demo access; none is enabled by default.) Six skills are exposed today. The first four are credential-free, no-LLM/deterministic and synchronous. The last two — submit_conversion and get_conversion_status — are GOVERNED and METERED: they require a per-user API token (jvx_…, not the shared key), enforce plan limits + credits, and run/read a real billed job. 1. convert_sql — deterministic-first SQL dialect conversion (no AI). Input data: { "skill": "convert_sql", "source", "target", "sql" }. Returns { output, compile_green, needs_ai, engine, provenance }. needs_ai=true flags the long tail that a full run would route to the AI + assurance pipeline. 2. prove_sql_equivalence — the DuckDB assurance oracle. It runs a source SQL and a candidate target SQL against a synthetic in-process fixture and diffs the result rows. Input data: { "skill": "prove_sql_equivalence", "source", "target", "source_sql", "target_sql" }. Returns { equivalent (true / false / null), tier, row_counts, ... }. A wrong conversion returns equivalent:false — this is JarvisX's "we prove it" thesis, callable directly. Both SQLs are SELECT-only and run in-process; null means inconclusive. 3. convert_schema — deterministic DDL/schema conversion (no AI). Input data: { "skill": "convert_schema", "source", "target", "sql" } where sql is DDL / CREATE statements. Returns { output, compile_green, needs_ai, engine }. 4. assess_estate — a source-only Migration Readiness Assessment. Input data: { "skill": "assess_estate", "artifacts": [ { "name", "content", "dialect?", "artifact_kind?" } ], "target?" }. Builds the estate dependency graph and returns asset_count, risk_distribution, a migration wave_plan, the business-critical assets (by blast radius) and recommendations — deterministic, no LLM, no production data. 5. submit_conversion (GOVERNED + METERED) — submit a real conversion job that runs asynchronously through the full AI + quality + assurance pipeline. Requires Authorization: Bearer jvx_… (a per-user token, not the shared key). Input data: { "skill": "submit_conversion", "product" (query | code | flow | schema), "source", "target", "artifacts": [ { "name", "content" } ] }. Plan limits + credits are enforced and the job is billed to that account. Returns { job_id, status: "submitted", artifacts_submitted }. 6. get_conversion_status (GOVERNED) — read the status of a job you submitted. Input data: { "skill": "get_conversion_status", "job_id" }. Requires the same per-user token; only returns jobs owned by that account. Returns { status, quality_score, output_available, download, ... }. Example JSON-RPC request for prove_sql_equivalence: POST https://gojarvisx.ai/a2a Authorization: Bearer jvx_your_token_here Content-Type: application/json { "jsonrpc": "2.0", "id": "1", "method": "message/send", "params": { "message": { "role": "user", "parts": [ { "kind": "data", "data": { "skill": "prove_sql_equivalence", "source": "teradata", "target": "bigquery", "source_sql": "SELECT id, amount FROM sales", "target_sql": "SELECT id, amount FROM sales" } } ] } } }

JarvisX also speaks the Model Context Protocol (MCP), so any MCP client — Claude Desktop, Cursor, an IDE copilot, or an ADK/LangGraph agent — can discover and call the same skills as tools. This is the "assurance-as-a-service" idea: an external agent (or even a rival converter) can call JarvisX to PROVE a conversion it produced — bring your own converter, we sign the proof. Note: the MCP server is feature-flagged and, when enabled, requires a bearer token (same auth as A2A: a platform API token jvx_… or the configured shared key). Endpoint: POST https://gojarvisx.ai/mcp — MCP Streamable HTTP transport (JSON-RPC 2.0), request/response (no server-initiated stream). Handshake with initialize, then tools/list, then tools/call. Send Authorization: Bearer <token>. The six tools mirror the A2A skills exactly. The first four are credential-free and synchronous; the last two (submit_conversion, get_conversion_status) are metered and require a per-user token (jvx_…). 1. convert_sql — deterministic-first SQL dialect conversion (no AI). Arguments: { "source", "target", "sql" }. Returns the converted SQL, compile_green, and needs_ai. 2. prove_sql_equivalence — the DuckDB assurance oracle. Arguments: { "source_sql", "target_sql" } (+ optional source/target dialect hints). Returns equivalent (true/false/null) with row counts — a credential-free row-diff proof on a synthetic fixture. 3. convert_schema — deterministic DDL/schema conversion (no AI). Arguments: { "source", "target", "sql" } where sql is DDL. Returns the converted DDL, compile_green, and needs_ai. 4. assess_estate — a source-only Migration Readiness Assessment. Arguments: { "artifacts": [ { "name", "content", "dialect?", "artifact_kind?" } ], "target?" }. Returns asset_count, risk_distribution, a migration wave_plan, business-critical assets and recommendations — deterministic, no LLM, no production data. 5. submit_conversion (metered) — submit a real async conversion job. Arguments: { "product" (query|code|flow|schema), "source", "target", "artifacts": [ { "name", "content" } ] }. Requires a per-user token; enforces plan limits + credits. Returns { job_id, status }. 6. get_conversion_status — read a job you submitted. Arguments: { "job_id" }. Ownership-scoped. Returns { status, quality_score, output_available, download }. Example tools/call request: POST https://gojarvisx.ai/mcp Authorization: Bearer jvx_your_token_here Content-Type: application/json { "jsonrpc": "2.0", "id": "1", "method": "tools/call", "params": { "name": "prove_sql_equivalence", "arguments": { "source": "teradata", "target": "bigquery", "source_sql": "SELECT id, amount FROM sales", "target_sql": "SELECT id, amount FROM sales" } } } The result carries a content[] text block (JSON) plus structuredContent with the same verdict.

JarvisX is aligned to SOC 2 Trust Services Criteria. Data at rest is encrypted via AES-256 (CMEK keys available for Enterprise). TLS 1.3 is enforced globally with HSTS preloading. GCS buckets are regional (hosted in US; EU region-pinning available on Enterprise request). We support self-serve GDPR data deletion/export and offer a 72-hour breach notification SLA.