The First Universal Transpiler: 10 Languages In, 14 Out

Every transpiler in existence converts one language to one other language. BRIK-64 converts any of 10 to any of 14 — with formal certification that the output is equivalent to the input.

Transpiler, Compiler, Interpreter — What's the Difference?

A compiler translates source code into machine code — something the CPU executes directly. GCC compiles C to x86. Rustc compiles Rust to native binaries. The output is low-level: registers, memory addresses, jump instructions.

An interpreter reads source code and executes it line by line. Python's CPython reads your .py file and runs it immediately. No binary is produced. The source is the program.

A transpiler (source-to-source compiler) translates one high-level language into another high-level language. The output is still human-readable code — not machine instructions. TypeScript transpiles to JavaScript. CoffeeScript transpiles to JavaScript. Babel transpiles modern JavaScript to older JavaScript.

Notice the pattern? Every transpiler you've ever used converts one language to one other language. TypeScript → JS. Sass → CSS. Kotlin → JVM bytecode. They are all 1-to-1.

Why All Existing Transpilers Are 1-to-1

Building a transpiler is hard. You need to understand the source language's syntax, semantics, type system, edge cases, and runtime behavior. Then you need to map all of that onto the target language's equivalent constructs. A single mismatch — integer overflow behavior, floating-point precision, string encoding — and the transpiled code behaves differently from the original.

This is why every transpiler is purpose-built for one pair of languages. The TypeScript compiler understands TypeScript and generates JavaScript. That's it. It doesn't also generate Python. It doesn't accept Rust as input. The complexity of maintaining semantic fidelity across even one language pair is enormous.

Now multiply that by 10 input languages and 14 output targets. That's 140 possible transpilation paths. No team on Earth builds and maintains 140 transpilers.

Unless you change the architecture entirely.

The N-to-N Architecture

BRIK-64 doesn't build 140 transpilers. It builds 10 frontends (one per input language) and 14 backends (one per output target), connected through a single universal intermediate representation: PCD (Printed Circuit Description).

The architecture is simple:

Source Language → Lifter → PCD Blueprint → TCE Check → Backend → Target Language

Each frontend (the "Lifter") analyzes source code and maps it onto BRIK-64's 64 formally verified atomic operations — monomers. The result is a PCD blueprint: a circuit schematic that describes what the code does, not how it does it. Each backend reads that blueprint and emits idiomatic, clean code in the target language.

This is the same insight behind LLVM. LLVM doesn't build a separate compiler for every language-to-architecture pair. It builds frontends (Clang for C, rustc for Rust) that emit LLVM IR, and backends that convert IR to x86, ARM, RISC-V. N frontends + M backends = N×M paths with N+M effort.

BRIK-64 applies the same principle to source-to-source transpilation. But with one critical addition that LLVM doesn't have: formal certification.

The Command

Transpiling code with BRIK-64 is a single command:

brikc transpile ./src/ --to rust --output ./dist/

That's it. Point it at a directory of JavaScript, Python, Go, C, COBOL — whatever you have. Tell it the target. Get certified, idiomatic output.

Behind the scenes, the command executes the full pipeline: lift → analyze → generate PCD → certify with TCE (Φ_c = 1) → emit target code → write output files.

Real Example: COBOL Banking to Go

Consider a COBOL program that calculates compound interest — the kind of code that runs in thousands of banks worldwide, written in the 1980s, maintained by engineers who are retiring:

brikc transpile interest_calc.cob --to go --output interest_calc.go

The Lifter analyzes the COBOL source, identifies the arithmetic operations (multiply, add, comparisons), maps them to verified monomers, generates a PCD blueprint, certifies it with Φ_c = 1, and emits clean Go code. The Go output does exactly what the COBOL did — not because a heuristic guessed at the semantics, but because both are projections of the same formally verified circuit.

The same COBOL can also be transpiled to Rust, Python, Java, or any other target. Every output is certified equivalent. Every output carries the same Φ_c = 1 guarantee.

Why Certification Changes Everything

Existing migration tools — AI-powered code converters, LLM-based translators — can generate plausible-looking output. But "plausible-looking" is not "equivalent." An LLM that converts Python to Rust might get the happy path right but silently change integer overflow behavior, exception handling, or floating-point rounding.

BRIK-64 doesn't guess. The Lifter maps source code onto a finite algebra of 64 verified operations. The TCE certifies that the resulting circuit is closed — every input consumed, every output produced, zero information leakage. The backend emits code from that certified blueprint. The guarantee is mathematical, not statistical.

This is the difference between "our AI says the code looks right" and "the algebraic structure proves the code is equivalent."

The Full Pipeline

Here's what happens when you run brikc transpile:

1. Lift. The frontend parses the source language, identifies functions and operations, and maps them to BRIK-64 monomers. Pattern matching recognizes common idioms: Math.abs(x) in JavaScript becomes the ABS monomer, len(s) in Python becomes LEN, x >> 3 in C becomes SHR.

2. Analyze. The analyzer checks liftability — can this function be represented entirely with core monomers? Functions that map completely get CORE certification (Φ_c= 1). Functions that use extended operations (file I/O, network calls) get CONTRACT certification. Functions that can't be mapped are flagged as unliftable.

3. Generate PCD.The emitter produces a .pcd file — a Printed Circuit Description — that captures the program's logic as a composition of monomers connected by EVA algebra operators (sequential, parallel, conditional).

4. Certify. The TCE engine measures seven properties of the circuit and computes Φ_c. If Φ_c = 1, the circuit is closed and the program is certified correct.

5. Emit. The backend reads the PCD blueprint and generates idiomatic code in the target language — proper naming conventions, language-specific patterns, correct types.

6. Execute.The output code runs natively in the target language's ecosystem. No runtime dependencies, no BRIK-64 library required.

Supported Languages

10 Input Languages (Lifter): JavaScript, TypeScript (TSX/JSX), Python, Rust, C, C++, Go, COBOL, PHP, Java.

14 Output Targets (Backends): Rust, JavaScript, TypeScript, Python, C, C++, Go, COBOL, PHP, Java, Swift, WebAssembly, BIR (bytecode), Native x86-64.

Every input-to-output combination works through the same PCD intermediate representation. 10 × 14 = 140 transpilation paths, all certified.

What's Next

The transpiler handles individual functions and modules today. The next milestones are:

Module resolution — following imports and dependencies across files to transpile entire projects, not just individual functions.

Full codebase conversion — pointing the transpiler at a complete repository and producing a fully functional project in the target language, with build files, dependency manifests, and project structure.

Cross-target consistency verification — proving that the same PCD blueprint, emitted to JavaScript and Rust and Python, produces identical outputs for identical inputs across all targets.

The universal transpiler is not a vision. It works today. 10 languages in, 14 out, every path certified.