Compute Architecture

Start With Useful Work, Not the Processor

The objective is not to maximize the performance of any single processor. It is to increase useful computational capability relative to the total energy, movement, infrastructure, materials, coordination, and cost required to produce it.

That changes where optimization begins. Moving information consumes resources. Converting representations consumes resources. Broad synchronization and coordination consume resources. Keeping generalized capability active for work that could be handled closer to its state can also create unnecessary cost.

MFRCA therefore begins with locality. Frequent work should remain as close to its physical context as the available capability allows, while broader communication, coordination, or reasoning should be used when the local system is no longer adequate for the work. The architecture does not assume that everything should remain local; it asks whether broadening scope has become necessary enough to justify its cost.

Preserve What Is Already Adequate

One of the central principles is Minimum Necessary Transformation. Computing systems routinely move state, convert representations, increase precision, synchronize timing, or transfer work because an architectural boundary expects them to. MFRCA asks whether each transformation is actually necessary.

If information can remain where it is, moving it should require a reason. If its representation remains useful, translation should not happen automatically. If lower precision is adequate for the task, higher precision should not be purchased by default. If useful computation can occur where the relevant state already exists, the architecture should consider that before moving the state elsewhere.

The principle is straightforward even when implementation is difficult: preserve location, representation, precision, timing, configuration, and persistence when they remain adequate, and transform them when the work actually requires something different.

Rethinking State and Capability

Traditional architectures often treat computation as active while memory and storage are comparatively passive. MFRCA explores a different abstraction through a State-Capability Continuum, in which persistence and the ability to transform state are separate dimensions.

A persistent layer does not need to become a general-purpose computer to perform useful local work. It may be able to filter, compare, search, aggregate, validate integrity, or reduce information before that information moves farther through the system. Deeper processing remains available when the local capability is insufficient.

This creates the possibility of increasing the useful density of information as its scope broadens. Rather than continually moving raw state toward centralized computation, some transformation can occur near the state itself as long as required evidence, precision, security, and authority remain intact. The objective is not computation everywhere, but matching the capability and location of computation to the work that actually needs to be performed.

General Capability, Specialization, and Experience

Specialization can be highly efficient when a workload fits the capability, while general-purpose computation remains essential for work that is novel, irregular, or changing. MFRCA is intended to preserve both.

The current architecture treats a complete cluster as the minimum self-sufficient computing unit, with enough general and specialized capability to handle normal workloads locally while larger demands can expand recursively across additional clusters and broader scopes. General Compute remains a first-class capability rather than a central processor to which all work must eventually return.

Specialization is also intended to remain stable enough to avoid constant reconfiguration. When demand shifts, the system should first route work toward available capability and use generalized or composable resources where appropriate. Reconfiguration becomes worthwhile only when the mismatch persists strongly enough to justify the energy, latency, state movement, and validation required to change roles.

Experience may eventually influence this balance. If a relationship or workload recurs reliably, the system may be able to handle more of it through cheaper or more specialized execution. That movement has to be earned, however, by both adequate evidence and enough expected reuse to justify the specialized path. Novelty moves in the opposite direction: when the learned relationship no longer fits what is happening, broader capability should reopen rather than forcing an unfamiliar problem through an inadequate specialization.

State Should Reflect Future Value

Not all information remains equally valuable over time. Some state must remain exact. Some may eventually be reconstructable. Other information may retain most of its future value as a relationship, trend, or learned pattern rather than as a complete copy of every original observation.

MFRCA therefore treats temporal relevance as part of state management. Retention should reflect what later work may reasonably need instead of assuming that every representation must persist indefinitely at its original fidelity.

That does not mean replacing evidence with approximation whenever compression is convenient. Where later verification, reinterpretation, causality, accountability, or recovery may depend on the original information, the architecture has to preserve an appropriate evidence path. The larger goal is to distinguish information that needs continued exactness from information whose value can be retained more economically in another form.

Efficiency Has to Survive the Whole System

A new architecture would not be valuable simply because one component uses less energy or one simulated workload runs faster. Any meaningful advantage has to survive the full cost of communication, conversion, synchronization, reliability, cooling, manufacturing, software transition, compatibility, maintenance, materials, and the enormous investment already embodied in conventional computing.

The research therefore includes a Revolutionary Advantage Gate. MFRCA ultimately has to demonstrate a substantial whole-system advantage against the best plausible future evolution of conventional architectures, not merely against today's CPU or GPU baseline. If conventional systems can absorb most of the useful mechanisms through improved accelerators, chiplets, packaging, memory, software, or orchestration at far lower switching cost, the appropriate outcome would be to transfer those mechanisms rather than defend a clean-sheet architecture for its own sake.

A Research Architecture

MFRCA remains theoretical. Its current virtual models are intended to expose relationships, sensitivities, failure modes, and break-even conditions rather than establish measured hardware performance. The architecture is being developed alongside explicit falsification questions covering workload adequacy, specialization, reconfiguration, distributed coordination, compatibility, AI scaling, reliability, manufacturing, and total economic advantage.

That evidence discipline matters because a clean-sheet architecture can become internally coherent while still being unnecessary, economically impractical, or inferior to a more conventional evolution. The relevant question is not whether MFRCA can become an interesting architecture on paper, but whether enough of its propositions survive progressively more realistic testing to justify building something materially different.

Relationship to AI Systems

Compute Architecture and AI Systems remain separate research programs, but they increasingly encounter the same efficiency problem from different layers.

AI Systems asks how much reasoning, memory, retrieval, coordination, and computation are actually necessary to produce a useful result. Compute Architecture asks how the computation that remains might be executed with less movement, transformation, energy, latency, and infrastructure.

Neither project depends on the other being correct. The more interesting possibility is that improvements at both layers could eventually compound: more selective intelligence asking the computing system to perform less unnecessary work, and a computing architecture able to perform the necessary work more efficiently.