Skip to main content

​
BRIK-64 Roadmap

BRIK-64 is not a product with a backlog. It is a formal artifact with a convergence path — each phase closes a provable gap between where software is and where hardware physics requires it to be. The ultimate goal is the BRIK Processing Unit (BPU): a chip where 64 verified monomers exist in silicon, and the EVA Router enforces circuit closure at the gate level. At that point, a certified program does not just behave correctly — it cannot misbehave, because the substrate does not permit it.
The current release is v4.0.0-beta.2 — 128 monomers (64 Core + 64 Extended) with the self-hosting fixpoint. The compiler compiles itself and produces an identical hash across 4 generations: 7229cfcde961.... This is the foundation everything below builds on.

​
Timeline

Phase 1 — Self-Hosting Fixpoint

v2.0.0 · Released March 2026 (fixpoint achievement)The compiler (brikc) is now a certified BRIK-64 program that compiles itself. Four consecutive self-compilation generations produce the same cryptographic hash — the fixpoint is proven.
DeliverableStatus
64 Core Monomers (MC_00–MC_63) with Coq proofsComplete
EVA Algebra (⊗ ∥ ⊕) — associativity + closure proofsComplete
TCE — Φ_c, ΔN, Cₘ, Ω metricsComplete
Self-hosting fixpoint: Gen1 = Gen2 = Gen3 = Gen4Complete
Native x86-64 ELF — 708 KB, no Rust runtime, no libcComplete
5 compilation targets: native, Rust, JS, Python, WASMComplete
Native libraries: brik64-core, @brik64/core, brik64Complete

Phase 2 — Extended Monomers

v4.0.0-beta.2 · March 2026 · Complete64 additional monomers covering the real-world surface area that Core deliberately excludes: floating point, networking, graphics, audio, concurrency, and foreign interop. Extended monomers operate under declared contracts (CONTRACT closure), not Coq proofs.The architectural invariant: Extended monomers may only be leaves. The main data flow must pass through Core before OUTPUT. The compiler enforces this boundary statically at every call site.
FamilyRangeStatus
Float64MC_64–71Complete
MathMC_72–79Complete
NetworkMC_80–87Complete
Filesystem+MC_104–111Complete
GraphicsMC_88–95Complete
AudioMC_96–103Complete
ConcurrencyMC_112–119Complete
Interop/FFIMC_120–127Complete
Programs mixing Core and Extended compile with --open and receive the BRIK-64 Open badge showing Core coverage percentage:
brikc compile src/server.pcd --open   # BRIK-64 Open 84% — Core coverage

Phase 3 — Certification Registry

v5.0.0 · 2026–2027The Certification Registry is the public, immutable index of certified BRIK-64 circuits. Every program with Ω = 1 can be submitted, and published as a Circuit Package — a certified, reusable PCD module that others can import exactly like an npm package or a Cargo crate.The key difference: every circuit package in the registry has been formally proven correct. You are not importing someone’s library. You are importing a certified circuit whose behavior is permanently recorded in the BRIK-64 Certification Registry.How certification works:

Author writes PCD

Compile with brikc compile src/circuit.pcd — the CMF verifier runs automatically and computes Φ_c.

Submit to Registry

brikc publish sends the certified artifact to the Registry API with the full TCE audit.

Hash published to registry

The hash is published to the BRIK-64 Registry. Once committed, neither the author nor BRIK-64 can silently change it.

Circuit Package published

Others can import and use the circuit. The compiler verifies the import hash against the registry before every build.
Circuit Packages work like npm/PyPI/crates.io, with one fundamental difference: only circuits with Ω = 1 can be published.
# Publish a circuit package
brikc publish src/hash_pipeline.pcd --name brik64/hash-pipeline --version 1.0.0

# Import a certified circuit in PCD
import { hash_pipeline } from "brik64/hash-pipeline@1.0.0";
When you import a circuit package, the compiler verifies the import hash against the registry before compilation proceeds. If the hash does not match, compilation fails.Every published circuit is recorded in the BRIK-64 Registry:
{
  "package": "brik64/hash-pipeline@1.0.0",
  "tce": { "phi_c": 1.000, "delta_n": 0.000, "c_m": 1.000, "omega": 1 },
  "hash": "sha256:7229cfcde961...",
  "registry": "registry.brik64.dev",
  "timestamp": "2027-03-01T00:00:00Z"
}
Live badge endpoints:
![BRIK-64 CERTIFIED](https://badge.brik64.dev/7229cfcde961)
The badge is a live REST endpoint. A modified program (hash mismatch) shows INVALID instantly — without any action from the author.Pro tier:
FeatureFreePro
Compile and certify locallyYesYes
Download and use circuit packagesYesYes
Submit programs to the public registry—Yes
Publish circuit packages—Yes
Private registry for internal circuits—Yes
Live badge endpoints for README—Yes
Revocation management—Yes
Priority TCE audit queue—Yes

Phase 4 — Multi-Platform Targets

v6.0.0 · 2027Extend the native compilation backend to ARM64 and RISC-V, enabling BRIK-64 certified programs to run as standalone binaries across all major embedded and server platforms.
TargetStatus
x86-64 ELFComplete (v2.0.0)
WASM32Complete (v2.0.0)
ARM64 (Apple Silicon, Raspberry Pi, AWS Graviton)Planned
RISC-V (embedded, FPGA softcore)Planned
Bare-metal (no OS, startup stub only)Planned

Phase 5 — BRIK Processing Unit

BPU · 2027–2028 · Prototype siliconThis is the long-horizon goal of the entire BRIK-64 project. The BPU is a hardware coprocessor where the 64 Core monomers are not software functions — they are silicon gates. EVA composition is an electrical routing problem. TCE certification happens at clock speed.The fundamental shift:Today, a certified BRIK-64 program proves that incorrect behavior cannot be expressed in source. With the BPU, incorrect behavior cannot occur in execution — because the silicon substrate physically prevents it.
PhaseToday (Software)With BPU (Hardware)
SourcePCD programPCD program
CompilerProves “cannot express undefined behavior”Proves “cannot execute undefined behavior”
RuntimeCPU (software enforced)BPU gates (physically enforced)
The difference is the same as the difference between a seatbelt (behavioral) and a speed limiter (physical). RLHF teaches AI to want to behave correctly. The BPU makes it impossible to behave incorrectly.BPU architecture layers:

Monomer Units

64 hardwired silicon gates — one per monomer. MC_00.ADD8 is a circuit, not a function.

EVA Router

Sequential (⊗), parallel (∥), and conditional (⊕) composition enforced as electrical routing.

TCE Unit

Φ_c = 1 checked at clock speed. BLOCK signal is non-maskable — software cannot override it.
BPU execution phases:
PhaseTargetDescription
Phase 1 (now)v4.0.0-beta.2+PCD policy circuits as software. ALLOW/BLOCK enforced by certified program on standard CPU.
Phase 22027FPGA implementation. Full BPU synthesized on Xilinx/Intel FPGA. All 64 monomers, EVA Router, TCE Unit. Validated against software.
Phase 32028ASIC tape-out. Custom silicon. BLOCK signal non-maskable at the pin level — software cannot override it.
Phase 42029+Industry standard for AI safety coprocessors. Regulatory path: voluntary → standard → mandatory.
BPU and AI Safety:
  1. Today — AI action → PCD policy circuit (software) → ALLOW or BLOCK
  2. Phase 2 — AI action → PCD policy circuit → BPU (FPGA) → ALLOW or BLOCK at hardware speed
  3. Phase 3 — AI action → BPU (ASIC) → ALLOW or BLOCK at gate speed — the CPU never sees a blocked action
Once a PCD policy circuit is compiled and loaded onto a BPU, circuit closure (Φ_c = 1) cannot be broken by software. The AI system cannot patch its own constraints because the constraints are in silicon, not in memory.
“RLHF teaches AI to want to do right. BPU prevents it from doing wrong. Education fails. Physics does not.”

​
Summary

VersionTargetKey Deliverable
v2.0.0March 2026Self-hosting fixpoint · 64 Core Monomers · Native ELF
v4.0.0-beta.2March 2026128 Monomers (64 Core + 64 Extended) · CONTRACT closure
v5.0.0Q2 2026Certification Registry · Circuit Packages · MCP Server
v6.0.0Q2 2027ARM64 + RISC-V backends · Bare-metal targets
v7.0.02027Package Manager
v8.0.02027Publication (Zenodo, arXiv, USPTO)
v9.0.02028BPU Hardware · ASIC tape-out · Non-maskable BLOCK
Dates are estimates. The self-hosting fixpoint (v2.0.0) is the only milestone that is both complete and immutable — subsequent phases may shift as the formal theory evolves.

Architecture

How monomers, EVA, and TCE work together

Theory: BPU

BPU architecture and the hardware safety model

AI Safety

Policy circuits and the ALLOW/BLOCK model