Back to Archive
DEEP DIVETheory

EVA Algebra: Sequence, Parallel, Conditional

How three composition operators carry sequencing, fan-out, and branching through the circuit model, and what that means for compiler readability and closure.

2026-03-01T00:00:00.000Z
Editorial cover for EVA Algebra: Sequence, Parallel, Conditional

The Problem Every Developer Knows

In electronics, composition is solved. If Gate A is correct and Gate B is correct, wiring A's output to B's input gives you a correct A-B circuit. That is not hope — it is Kirchhoff's laws. The voltages and currents are governed by algebra, and that algebra is closed under composition. Hardware engineers have had this guarantee since 1845.

Software has nothing like it. Function A works. Function B works. Call A then B and it might crash, might deadlock, might produce garbage. There is no algebraic law that guarantees the composition works. Every integration is a prayer. Every microservice boundary is a gamble. Every API contract is a handshake agreement that nobody enforces.

EVA — Entropic Verification Algebra — changes that. It is the formal algebraic system that gives software the same composability guarantees that hardware has had for 180 years. Three operators. Strict laws. Composition that preserves correctness by construction.

Three Operators. That Is It.

EVA has exactly three composition operators. Every program in PCD is built from these three operations applied to the 128 atomic monomers (64 core + 64 extended). Nothing else exists. Nothing else is needed. Other languages have hundreds of ways to combine code. EVA has three — and they are all mathematically certified.

Sequential Composition (Tensor)

A sequential B means: execute A, then feed A's output into B's input. The output type of A must match the input type of B. This is the most fundamental operator — a pipeline. Other languages let you pipe incompatible types and crash at runtime. EVA catches it at compile time.

// Sequential: output of one operation feeds into the next
// A pipeline that computes price + tax
// The compiler verifies
type compatibility at each step

The key property: if A is certified (Phi C = 1) and B is certified (Phi C = 1), then A sequential B is certified. Correctness composes sequentially. This is mathematically certified — not tested, proven.

Parallel Composition

A parallel B means: execute A and B independently, on separate inputs, producing separate outputs. No data dependency. They can run simultaneously. No locks. No mutexes. No race conditions.

// Parallel: two independent calculations
// e.g., temperature conversion and distance conversion
// running independently with no shared state

The key property: if A and B share no state, their parallel composition is automatically correct. The algebra forbids shared mutable state between parallel branches. Other languages give you threads and hope you get the locking right. EVA makes data races structurally outside the declared model.

Conditional Composition (Direct Sum)

A conditional B means: based on a condition, execute either A or B — never both. This is branching, but with a critical constraint: both branches must produce the same output type. No unhandled cases. No forgotten else clauses.

// Conditional: one path or the other
// Based on a predicate, choose branch A or branch B
// Both branches must produce the same output type
// The compiler verifies totality: every case is covered

The key property: if both branches are certified and the condition is total (always evaluates to true or false, never undefined), then the conditional composition is certified. Every execution path is covered. Other languages let you forget an edge case and ship a bug. EVA makes totality a compile-time requirement.

The Algebraic Laws

These three operators obey strict algebraic laws — associativity, commutativity, distributivity, and identity — all mathematically certified. The laws guarantee that refactoring is safe, parallelization is automatic, and optimizations preserve behavior. The compiler can transform your code freely because the algebraic structure guarantees semantic equivalence across transformations. No other programming language can make this claim.

Why This Matters to You

These are not abstract mathematical curiosities. They have direct, practical consequences for every line of code you write:

Refactoring is safe. Associativity means you can break a long pipeline into smaller named circuits and compose them back. The result is provably identical. No refactoring regression. Ever.

Parallelization is automatic. Commutativity of parallel composition means the compiler parallelizes independent computations without a single annotation from you. No async/await. No thread pools. No race conditions. The algebra handles it.

Optimization is provably correct. Distributivity means the compiler can inline, factor, and reorder your code — and the algebraic laws guarantee the transformation preserves behavior. Other compilers optimize and hope nothing breaks. BRIK64 optimizes and proves nothing can.

Composition preserves certification. This is the crown jewel. If every monomer in a circuit is certified (Phi C = 1), and every composition follows the three EVA operators, then the entire circuit is certified. Correctness scales. It does not degrade as the program grows. It composes. Build a 10-line circuit or a 10,000-line system — the guarantee is identical.

The Closure Theorem

EVA has a fundamental closure theorem, mathematically certified: if two components are certified (Phi C = 1), then any composition of them — sequential, parallel, or conditional — is also certified. The space of correct programs is closed under composition. You cannot compose correct parts and get an incorrect whole. The algebra prevents it.

In hardware, this is obvious — Kirchhoff's laws guarantee it. In software, before EVA, it was outside the declared model. Now it is a theorem with 207 proof files behind it.

EVA sits in a unique position among verification approaches: full composability guarantees with automatic verification and practical usability. The finite monomer space (128 operations) is what makes this possible. You cannot do this with an infinite language. The constraint is the feature.

Building with EVA

Every PCD program you write is an EVA expression. When you write:

// A simple circuit composing operations:
// addition >> multiplication | identity
// The compiler checks algebraic laws at each step

The compiler sees the algebraic structure of your program. It checks the laws. It verifies type compatibility at every composition point. It proves closure. And when it reports Phi C = 1, it is not saying "all tests passed." It is saying "the algebraic structure is sound."

That is the difference between testing and proof. Tests check examples. Algebra checks structure. EVA checks structure — all 110,000+ tests confirm it, but the proofs are what guarantee it.

The math does the heavy lifting. You just compose. Start building.

More reading

Continue the archive

Full archive
Technical BRIK64 diagram showing an AI coding prompt transformed into a reviewable blueprint, human review checkpoint, and target outputs.
AI safetyUncategorized

Reviewable AI Coding Pipelines: From Prompt to Blueprint

AI-generated code workflows become more reviewable when teams separate the prompt, generated code, structural blueprint, human review, and target compilation.

Open article
BRIK64 editorial image showing AI-generated software becoming inspectable, certified, and compiled across targets.
AI-generated softwareUncategorized

Making AI-Generated Software Reviewable

AI-generated software can move quickly, but it still needs structure, traceability, and review boundaries. BRIK64 helps teams preserve the blueprint behind generated code.

Open article
Editorial cover for AI Governance Workflows Need Reviewable Technical Evidence
AI SAFETYAI Safety

AI Governance Workflows Need Reviewable Technical Evidence

How bounded software evidence can help teams carry AI governance reviews into compliance workflows without implying full legal coverage.

Open article
Editorial cover for Compiler Evidence: Targets, Proof Files, and Test Scope
ENGINEERINGEngineering

Compiler Evidence: Targets, Proof Files, and Test Scope

A summary of the public numbers that can be stated responsibly and the limits of what those numbers prove.

Open article
Editorial cover for Safety-Critical Software Needs a Readable Assurance Path
PRODUCTProduct

Safety-Critical Software Needs a Readable Assurance Path

How bounded software evidence can support engineering review in high-consequence domains without replacing the broader safety program.

Open article
Editorial cover for Bounded Contract Logic Before Deployment
PRODUCTProduct

Bounded Contract Logic Before Deployment

Why smart contract workflows benefit from explicit state boundaries, value constraints, and reviewable rule sets before deployment.

Open article
Editorial cover for What the Proof Material Means for Users
VISIONFoundations

What the Proof Material Means for Users

A practical note on the proof files behind the compiler and what remains invisible to a normal authoring workflow.

Open article
Editorial cover for Why a New Format Instead of Another General-Purpose Language
VISIONFoundations

Why a New Format Instead of Another General-Purpose Language

Why BRIK64 introduces PCD as a bounded computational format rather than extending a conventional language with another annotation layer.

Open article
Editorial cover for Adversarial Testing Against the Compiler Chain
ENGINEERINGEngineering

Adversarial Testing Against the Compiler Chain

How the team tries to break the compiler and what those tests can and cannot prove about the formal system.

Open article
Editorial cover for Translation Validation Across Two Targets
RESEARCHResearch

Translation Validation Across Two Targets

A look at cross-target output comparison, what it can support, and what still depends on the bounded intermediate form.

Open article
Editorial cover for Why Tests Passing Is Not the Same as Closure
VERIFICATIONEngineering

Why Tests Passing Is Not the Same as Closure

A look at sampled testing versus bounded verification, with examples of logic that passed tests but still required stronger structural checks.

Open article
Editorial cover for One Blueprint Across Multiple Targets
PRODUCTProduct

One Blueprint Across Multiple Targets

How the transpilation chain uses PCD as a bounded intermediate form, what 10 source languages and 14 targets mean in practice, and where the equivalence claim stops.

Open article
Editorial cover for What AI Intuition Still Cannot Verify
AI SAFETYAI Safety

What AI Intuition Still Cannot Verify

Why intuition without an external proof path remains a risk, and where BRIK64 fits in that boundary.

Open article
Editorial cover for API and MCP Access Around the Registry
PLATFORMProduct

API and MCP Access Around the Registry

How discover-and-execute workflows expose registry and platform operations to humans and agents without enlarging the proof claim.

Open article
Editorial cover for Blueprints Before Refactors
REVOLUTIONProduct

Blueprints Before Refactors

How extracting bounded computation from an existing codebase can make rewrites and target changes easier to review.

Open article
Editorial cover for A Bounded JavaScript-to-Rust Workflow
TUTORIALGetting Started

A Bounded JavaScript-to-Rust Workflow

Lift the logic, review the bounded blueprint, then emit a target language while keeping the claim attached to the intermediate circuit.

Open article
Editorial cover for Lifting Existing Code into a Reviewable Blueprint
TOOLINGProduct

Lifting Existing Code into a Reviewable Blueprint

What the Lifter preserves, where liftability evidence exists in the repo, and how bounded blueprints help before migration.

Open article
Editorial cover for COBOL Migration Through Bounded Lift-and-Review
MIGRATIONProduct

COBOL Migration Through Bounded Lift-and-Review

Why legacy modernization benefits from lifting review-critical logic into a bounded blueprint before transpilation or replacement.

Open article
Editorial cover for Why AI-Generated Code Needs Blueprints and External Checks
PRODUCTAI Safety

Why AI-Generated Code Needs Blueprints and External Checks

Generated code and generated tests can fail together. This note explains why BRIK64 keeps verification outside the model loop.

Open article
Editorial cover for Which Parts of a Codebase Are Ready for Stronger Review?
PRODUCTProduct

Which Parts of a Codebase Are Ready for Stronger Review?

Use lifting and bounded analysis to identify review-critical functions before migration or certification work.

Open article
Editorial cover for Laszlo B. Kish and the Information-Theory Thread
RESEARCHResearch

Laszlo B. Kish and the Information-Theory Thread

A research profile on the ideas that influenced the information-theoretic framing behind Digital Circuitality.

Open article
Editorial cover for Informational Entropy Is Not Thermal Entropy
RESEARCHResearch

Informational Entropy Is Not Thermal Entropy

Why the distinction matters for the foundations story and how it sharpens the claim boundary around Digital Circuitality.

Open article
Editorial cover for From Preferences to Enforced Action Boundaries
AI SAFETYAI Safety

From Preferences to Enforced Action Boundaries

Why robotics and agent systems need explicit action gates, bounded state, and reviewable fallback paths.

Open article
Editorial cover for First PCD Circuit: A Minimal Walkthrough
TUTORIALGetting Started

First PCD Circuit: A Minimal Walkthrough

Install the CLI, write a small circuit, and inspect the bounded output path. A practical introduction to the format and the compile step.

Open article
Editorial cover for Working with the SDKs Without Leaving the Bounded Model
SDKSGetting Started

Working with the SDKs Without Leaving the Bounded Model

How the Rust, JavaScript, and Python SDKs expose BRIK64 patterns while keeping the formal core distinct from host-language code.

Open article
Editorial cover for Why Software Verification Still Looks Different from Hardware
RESEARCHResearch

Why Software Verification Still Looks Different from Hardware

A comparison between sampled software testing and the compositional review posture hardware teams expect.

Open article
Editorial cover for 128 Operations and the Boundary Between Core and Bridges
ENGINEERINGEngineering

128 Operations and the Boundary Between Core and Bridges

A tour of the reviewed core, the contract-bounded extensions, and what that split means for technical scope.

Open article
Editorial cover for PCD for AI Agents: A Small Format with an External Proof Loop
AI AGENTSAI

PCD for AI Agents: A Small Format with an External Proof Loop

How a finite grammar helps agents author bounded logic while the compiler and policy checks stay outside the model.

Open article
Editorial cover for Precision as a Declared Domain
ENGINEERINGEngineering

Precision as a Declared Domain

Why bounded numeric domains matter for floating behavior, decimal handling, and reviewable arithmetic.

Open article
Editorial cover for BPU: Policy Enforcement as a Hardware Roadmap
HARDWAREHardware

BPU: Policy Enforcement as a Hardware Roadmap

Why software-only guardrails share execution context with the model they constrain, and how the BPU roadmap moves policy enforcement toward FPGA and silicon.

Open article
Editorial cover for Policy Circuits for AI Safety Workflows
AI SAFETYAI Safety

Policy Circuits for AI Safety Workflows

How external policy circuits can gate generated code and agent actions without claiming to solve general alignment.

Open article
Editorial cover for What Digital Circuitality Tries to Formalize
VISIONFoundations

What Digital Circuitality Tries to Formalize

A bounded programming model built from reviewed operations, explicit composition, and closure checks.

Open article