Digital Circuitality
Digital Circuitality is the formal property of a computational system in which every possible execution path is bounded, typed, and thermodynamically closed — analogous to an electrical circuit where current cannot escape the circuit boundaries.
Formally, a system S exhibits Digital Circuitality if and only if:
where Φ_c (the coherence coefficient) is:
Φ_c = (1 − H_d/H_max) · (1 − ΔN) · (1 − ETC/ETC_max)
| Condition | Symbol | Meaning |
|---|
| Circuit Closure | Φ_c = 1.000 | Every branch has a complete path input→output. No dangling operations. |
| Entropy Delta | ΔN = 0.000 | Zero information loss or leakage. No logical noise. |
| Morphological Coherence | Cₘ = 1.000 | Clean composition with any compatible polymer via EVA algebra. |
Why Not Landauer?
Landauer’s principle — the claim that erasing one bit of information necessarily dissipates at least k_B · T · ln(2) joules of energy — has been influential in connecting computation to physics. However, it has been subject to rigorous critique. Kish, Granqvist, and Ferry (2018) argued that information entropy and thermal entropy are not interchangeable, questioning the standard interpretation that treats logical irreversibility as a direct physical cost (DOI: 10.1007/s10825-017-1044-1). Earlier work by Kish et al. (2016) further examined these foundational assumptions (DOI: 10.1007/s10825-015-0754-5).
Digital Circuitality does not depend on Landauer’s principle being true or false. The TCE measures information entropy (S_I), not thermal entropy. The key identity is:
A certified program (Φ_c = 1) is a deterministic system with zero information entropy — every input maps to exactly one output through every path. This is a statement about information, not about heat.
The ΔN metric measures logical noise: how much information your program destroys versus preserves. A program with ΔN = 0.000 is fully information-preserving — every operation’s output is uniquely determined by its input. This is a measure of computational determinism, not energy efficiency.
The Entropy Gap
The Entropy Gap is the distance between where your program operates informationally and where a fully deterministic system operates. It represents:
- Information loss from non-deterministic or under-specified logic
- Entropy production that propagates unpredictability through compositions
- The measurable distance between “it probably works” and “it is proven to work”
BRIK-64 makes this gap explicit and measurable. The TCE reports it for every program. Certified programs have an Entropy Gap of zero — they are fully deterministic.
Acknowledgment: Prof. Laszlo B. Kish (Texas A&M University) reviewed Digital Circuitality’s foundational framework and suggested the information-theoretic direction that separates it from physical thermodynamic claims.
Hardware Error Rate Context
Modern silicon operates at error rates of approximately 10⁻¹⁹ per operation — the physical noise floor of semiconductor logic at room temperature. This is the only error source that certified BRIK-64 programs are subject to. Logic errors, type errors, undefined behavior, and integer overflow are not measured as rare events — they are structurally impossible. The compiler rejects the program before it can run.
A certified BRIK-64 program has exactly one failure mode: the hardware running it fails first.
The Problem: Open Circuits in Software
Modern software runs as open circuits. There are no physical boundaries preventing computation from flowing into undefined states.
The consequences:
- A null pointer dereference opens a path that was never designed to exist
- An integer overflow routes computation through undefined behavior
- A race condition creates non-deterministic branching
- A supply-chain compromise injects foreign code into the circuit
These are mathematical singularities — points where the function is undefined. In classical mathematics, 1/0 is undefined. In software, the equivalent is an array out-of-bounds access, a use-after-free, or a type confusion. The computation reaches a point the designer never specified, and from that point, anything is possible.
Why Tests Cannot Close the Circuit
Testing checks specific paths. A test suite with 10,000 tests checks 10,000 of the ∞ possible inputs. The singularities you didn’t test for remain open.
Digital Circuitality closes the circuit structurally — not by testing more paths, but by making open paths impossible to construct in the first place. The compiler does not warn you. It refuses.
“You don’t make electrical wiring safe by testing every device you might plug in. You make it safe by building a closed circuit with proper insulation and circuit breakers.”
— Paper I: Post-Debt Software Paradigm
Digital Circuitry: The Discipline
Digital Circuitry is the engineering discipline of building programs as circuits — applying Digital Circuitality to software design.
Where Digital Electronics uses:
- Logic gates as atomic operations
- Boolean algebra for composition
- Physical laws as verification
Digital Circuitry uses:
- Monomers as atomic operations (64 Core + 64 Extended)
- EVA Algebra for composition (⊗ sequential, ∥ parallel, ⊕ conditional)
- TCE certification as verification (Ω = 1)
The PCD language (Printed Circuit Description) is the schematic language of Digital Circuitry — a formal language for describing circuits, not a scripting language for instructing a processor.
Digital Circuitality is a universal methodology. Its principles — finite operations, determinism, closed circuits, compositional verification — can be applied in any programming language. You can structure Python, Rust, or JavaScript code following circuit thinking, and your code will be better for it.
However, formal certification is exclusive to PCD programs compiled through brikc:
| Digital Circuitality (methodology) | BRIK-64 Certification (formal) |
|---|
| Scope | Any language, any codebase | PCD programs only |
| CMF metrics (Φ_c, δ, etc.) | Not available | Computed by brikc check |
| Φ_c = 1 proof | Not provable | Compiler-enforced |
| Registry badges | Not available | Issued for BIR-compiled programs |
| Certificates | Not available | Published to BRIK-64 Registry |
| Value | Better code quality | Mathematical proof of correctness |
Code written directly in Rust, Python, or JavaScript — even if it uses BRIK-64 monomer libraries — cannot be CMF-certified. Only programs written in PCD and compiled through the brikc pipeline produce certified output.
brikc compile --target, the generated code inherits the Φ_c = 1 proof from the PCD source. The proof happened at compile time — the target language is just the execution vehicle.
Use the principles everywhere. Certify through PCD.
Working with BRIK-64 Today
Digital Circuitality is available now through two paths — one for certification, one for methodology:
1. Write PCD — Full Certification Path
PCD is a full Turing-complete language. Write your program as a circuit schematic and compile to your target. This is the only path that produces formally certified output:
brikc compile src/main.pcd # Compile to native x86-64 ELF
brikc compile src/main.pcd --target rs # Emit certified Rust
brikc compile src/main.pcd --target js # Emit certified JavaScript (ES2022)
brikc compile src/main.pcd --target py # Emit certified Python 3.10+
brikc compile src/main.pcd --target wasm32 # Emit certified WebAssembly
2. Use BRIK-64 libraries — Methodology Path (No Certification)
BRIK-64 publishes monomer libraries for major languages. Import them to apply Digital Circuitality as a methodology inside your existing codebase:
// Rust — brik64-core crate (methodology only, NOT certified)
use brik64::{MC_00, MC_06, EVA};
let result = EVA::seq(MC_00::add8(a, b), MC_06::mod8(x, n));
# Python — brik64 package (methodology only, NOT certified)
from brik64 import mc, eva
result = eva.seq(mc.add8(a, b), mc.mod8(x, n))
// JavaScript — @brik64/core package (methodology only, NOT certified)
import { mc, eva } from '@brik64/core';
const result = eva.seq(mc.add8(a, b), mc.mod8(x, n));
3. Target languages summary
| Target | Flag | Output | Notes |
|---|
| Native x86-64 | (default) | Standalone ELF | No libc, no runtime — 100% self-contained |
| Rust | --target rs | .rs source | Idiomatic, zero-cost abstractions |
| JavaScript | --target js | .js (ES2022) | Node.js or browser |
| Python | --target py | .py (3.10+) | CPython compatible |
| WebAssembly | --target wasm32 | .wasm | Browser or WASI |
| BIR bytecode | --target bir | .bir | BRIK-64 bytecode IR, portable |
The 128 Monomers (64 Core + 64 Extended)
Certified programs are built from 64 Core atomic operations (8 families × 8), with 64 Extended monomers available for real-world I/O:
| Family | Range | Name | Operations |
|---|
| F0 | MC_00–07 | Arithmetic | ADD8, SUB8, MUL8, DIV8, INC, DEC, MOD, NEG |
| F1 | MC_08–15 | Logic | AND8, OR8, XOR8, NOT8, SHL, SHR, ROTL, ROTR |
| F2 | MC_16–23 | Memory | LOAD, STORE, ALLOC, FREE, COPY, SWAP, CAS, FENCE |
| F3 | MC_24–31 | Control | IF, JUMP, CALL, RET, LOOP, BREAK, CONT, HALT |
| F4 | MC_32–39 | I/O | READ, WRITE, OPEN, CLOSE, SEEK, STAT, POLL, FLUSH |
| F5 | MC_40–47 | String | CONCAT, SPLIT, SUBSTR, LEN, UPPER, CHAR_AT, TRIM, MATCH |
| F6 | MC_48–55 | Crypto | HASH, HMAC, AES_ENC, AES_DEC, SHA256, RAND, SIGN, VERIFY |
| F7 | MC_56–63 | System | TIME, SLEEP, ENV, EXIT, PID, SIGNAL, MMAP, SYSINFO |
7229cfcde9... reflects this: a compiler with a different hash has been modified.
BRIK-64 Open: Extended Monomers (MC_64–MC_127)
64 additional monomers connect certified logic to the real world — floating point, networking, graphics, audio, concurrency, FFI:
| Family | Range | Name | Operations |
|---|
| F8 | MC_64–71 | Float64 | FADD, FSUB, FMUL, FDIV, FABS, FNEG, FSQRT, FMOD |
| F9 | MC_72–79 | Math | SIN, COS, TAN, EXP, LN, LOG2, POW, CEIL |
| F10 | MC_80–87 | Network | TCP_CONN, TCP_SEND, TCP_RECV, UDP_SEND, DNS, HTTP_GET, HTTP_POST, TLS |
| F11 | MC_88–95 | Graphics | FB_INIT, FB_PIXEL, FB_LINE, FB_RECT, FB_BLIT, FB_FLIP, FB_TEXT, FB_CLOSE |
| F12 | MC_96–103 | Audio | AU_INIT, AU_PLAY, AU_STOP, AU_MIX, AU_VOL, AU_SEEK, AU_STREAM, AU_CLOSE |
| F13 | MC_104–111 | Filesystem+ | DIR_LIST, DIR_CREATE, DIR_DELETE, CHMOD, CHOWN, LINK, WATCH, TEMP |
| F14 | MC_112–119 | Concurrency | SPAWN, JOIN, CHAN_NEW, CHAN_SEND, CHAN_RECV, MUTEX, ATOMIC, YIELD |
| F15 | MC_120–127 | Interop/FFI | FFI_LOAD, FFI_CALL, FFI_ALLOC, FFI_FREE, WASM_EXEC, PY_EVAL, JSON_PARSE, JSON_EMIT |
Certification: The Public Registry
Every BRIK-64 certified program produces a cryptographic certificate:
{
"program": "my-crypto-lib",
"version": "2.1.0",
"tce": { "phi_c": 1.000, "delta_n": 0.000, "c_m": 1.000, "omega": 1 },
"badge_type": "certified",
"public_hash": "sha256:7229cf...",
"merkle_proof": { "root": "...", "registry": "registry.brik64.dev" },
"signature": "Ed25519:7fa3c9..."
}
brik64.dev/registry — an append-only, blockchain-anchored log of every certified program ever published. Only programs compiled to BIR through the brikc pipeline and registered through the certification system can receive these certificates.
The badge on a project’s README is not decorative. It is a live endpoint that verifies the certificate hash in real time against the registry. A modified program shows INVALID automatically — without any human intervention.
What Certification Means
A BRIK-64 Certified badge surpasses every existing software certification standard because it makes a fundamentally different claim:
| Standard | Claim | Mechanism |
|---|
| ISO 26262 (automotive) | “We followed the process” | Audit trail |
| DO-178C (avionics) | “We ran the tests” | Test coverage |
| Common Criteria EAL7 | ”We evaluated the design” | Expert review |
| BRIK-64 Certified | ”Incorrect programs cannot compile” | Structural impossibility |
Thermodynamic Coherence Engine (TCE)
The TCE computes Φ_c for every component and composition at compile time.
For every monomer MC_i, the TCE measures its thermodynamic profile T = (E_c, H_d, S_d, C_s, ETC, ΔN, Φ_c). For every polymer (composition), the TCE applies EVA algebra’s composition laws to derive the polymer’s profile from its monomers — and verifies that Φ_c = 1 is preserved.
This means verification is compositional: if every monomer is verified, and EVA composition rules preserve verification, then any valid BRIK-64 program of any size is verified. There is no combinatorial explosion in the test space, because there is no test space.
The Self-Compilation Fixpoint
The most important circuit to close is the compiler itself.
brikc compiles itself from brikc.pcd. The resulting binary, when used to compile the same source, produces an identical binary. The SHA-256 hash of this binary:
7229cfcde9613de42eda4dd207da3bac80d2bf2b5f778f3270c2321e8e489e95
- The compiler has no hidden state that changes between generations
- The entire toolchain can be verified from first principles
- Trust requires only trusting the source — not a pre-compiled binary from an unknown origin
This is Digital Circuitality applied to the build system itself: the compiler is its own closed circuit, and the hash is the proof.
