Initial commit

README.md

@@ -0,0 +1,21 @@
+# Patent Drafting Project
+
+Working title:
+
+**Systems and Methods for Executing Memory-Image-Defined Computation on a Cellular Automaton Computing Substrate**
+
+This project contains a working patent-application draft for a reconfigurable cellular automaton computing substrate based on a protected local evolution function `F`.
+
+## Files
+
+- `drafts/patent_application.md` - Main working patent application draft.
+- `drafts/claims.md` - Preliminary claim set for focused iteration.
+- `drafts/abstract.md` - Draft abstract.
+- `drafts/figures.md` - Suggested figure list and figure descriptions.
+- `notes/invention_disclosure.md` - Technical summary, invention boundaries, and open drafting questions.
+- `notes/glossary.md` - Working terminology.
+
+## Drafting Notes
+
+This is a technical drafting aid, not legal advice. A patent attorney or agent should review the final application, especially the claim strategy, prior art positioning, inventorship, enablement, and jurisdiction-specific formatting.
+

drafts/abstract.md

@@ -0,0 +1,4 @@
+# Abstract
+
+A computing system includes a memory array storing cell states of a cellular automaton and update circuitry configured to repeatedly apply a fixed local evolution function to the cell states. Executable computation is encoded as one or more cellular automaton state images loaded into the memory array. The state images may define virtual processor architectures, special-purpose accelerators, nonlinear simulation engines, routing structures, emitters, detectors, interaction regions, and output regions. Applying the fixed local evolution function evolves the loaded image such that computational results are produced in designated memory regions. In some embodiments, compact multi-bit cell states are packed into memory words to provide multiple independent cellular automaton cores, and integrity, redundancy, mirroring, or transform-based validation is applied across cores. The system permits effective hardware architectures and simulation machines to be updated by loading different state images without modifying the physical update circuitry implementing the evolution function.
+

drafts/claims.md

@@ -0,0 +1,97 @@
+# Preliminary Claims
+
+## Independent Claim 1: Computing Substrate
+
+1. A computing system comprising:
+   a memory array configured to store cell states of a cellular automaton;
+   update circuitry configured to repeatedly apply a fixed local evolution function to the cell states stored in the memory array; and
+   an image loader configured to load into the memory array a cellular automaton state image encoding an executable computation;
+   wherein the fixed local evolution function computes a next state for a cell from a current state of the cell and states of a bounded neighborhood of the cell;
+   wherein the cellular automaton state image comprises spatially arranged computational structures that evolve under the fixed local evolution function; and
+   wherein computational output is obtained by reading one or more designated output regions of the memory array after one or more applications of the fixed local evolution function.
+
+## Dependent Claims
+
+2. The computing system of claim 1, wherein the cell states comprise multi-bit cell states.
+
+3. The computing system of claim 2, wherein each cell state comprises a 6-bit value.
+
+4. The computing system of claim 1, wherein a memory word stores cell states for a plurality of independent cellular automaton cores.
+
+5. The computing system of claim 4, wherein a 64-bit memory word stores ten 6-bit cell states and one or more additional bits for metadata, parity, cyclic redundancy checking, or error detection.
+
+6. The computing system of claim 1, wherein the fixed local evolution function is cell-type-count preserving.
+
+7. The computing system of claim 1, wherein the fixed local evolution function is information-conserving.
+
+8. The computing system of claim 1, wherein the fixed local evolution function is reversible.
+
+9. The computing system of claim 1, wherein the spatially arranged computational structures comprise persistent propagating structures.
+
+10. The computing system of claim 9, wherein the persistent propagating structures comprise gliders.
+
+11. The computing system of claim 9, wherein the cellular automaton state image comprises interaction regions configured to cause persistent propagating structures to collide or interact to perform logic, routing, detection, emission, or transformation operations.
+
+12. The computing system of claim 1, wherein the cellular automaton state image defines an effective processor architecture.
+
+13. The computing system of claim 12, wherein the effective processor architecture comprises at least one of register regions, instruction-processing regions, memory-interface regions, routing regions, or output regions.
+
+14. The computing system of claim 1, wherein the cellular automaton state image defines a nonlinear simulation engine.
+
+15. The computing system of claim 14, wherein the nonlinear simulation engine is configured for at least one of particle simulation, radiation transport, plasma wakefield simulation, field propagation, collision cascade simulation, nonlinear wave computation, or spatial constraint solving.
+
+16. The computing system of claim 1, wherein loading a different cellular automaton state image changes an effective hardware architecture executed by the computing system without modifying the update circuitry implementing the fixed local evolution function.
+
+17. The computing system of claim 1, wherein the fixed local evolution function is implemented by an application-specific integrated circuit.
+
+18. The computing system of claim 1, wherein the fixed local evolution function is implemented by near-memory processing circuitry or processing-in-memory circuitry.
+
+19. The computing system of claim 1, wherein the update circuitry applies a pull-based update in which each cell computes and writes only its own next state.
+
+20. The computing system of claim 19, wherein simultaneous neighbor influences are collected into a local pattern and mapped to the next state without selecting a winning influence according to a fixed global direction priority.
+
+21. The computing system of claim 19, wherein the fixed local evolution function is equivariant under one or more lattice rotations, reflections, coordinate inversions, or coordinate permutations.
+
+22. The computing system of claim 19, wherein a deterministic priority orientation for resolving simultaneous neighbor influences varies across cells, rows, planes, tiles, or cores according to a balanced spatial pattern.
+
+23. The computing system of claim 22, wherein the balanced spatial pattern assigns each of a plurality of lattice directions an equal number of priority assignments within a repeating supercell.
+
+24. The computing system of claim 22, wherein the deterministic priority orientation is derived from address bits of a cell location.
+
+25. The computing system of claim 1, further comprising validation circuitry configured to compare outputs from two or more independent cellular automaton cores.
+
+26. The computing system of claim 25, wherein the two or more independent cellular automaton cores execute mirrored, rotated, coordinate-transformed, or otherwise transformed versions of the cellular automaton state image.
+
+27. The computing system of claim 1, wherein the cellular automaton state image comprises one or more emitter structures configured to generate persistent propagating structures under the fixed local evolution function.
+
+28. The computing system of claim 1, wherein the cellular automaton state image comprises one or more detector structures configured to alter one or more output regions in response to arrival of persistent propagating structures.
+
+29. The computing system of claim 1, wherein the executable computation is encoded primarily as a spatial configuration rather than as a sequential instruction stream.
+
+30. The computing system of claim 1, wherein update cost for a fixed lattice region is determined primarily by a number of cells updated rather than by a number of pairwise interactions represented within the cellular automaton state image.
+
+## Independent Claim 31: Method
+
+31. A method of executing a computation, comprising:
+   storing cell states of a cellular automaton in a memory array;
+   loading into the memory array a cellular automaton state image that encodes an executable computation;
+   repeatedly applying, by update circuitry, a fixed local evolution function to the cell states, wherein the fixed local evolution function computes next states from bounded neighborhoods of cells;
+   evolving the cellular automaton state image into one or more output states; and
+   reading one or more designated output regions of the memory array to obtain a result of the executable computation.
+
+32. The method of claim 31, further comprising loading a second cellular automaton state image that defines a different effective processor, accelerator, or simulation engine without modifying the fixed local evolution function.
+
+33. The method of claim 31, wherein the cellular automaton state image directly implements a nonlinear simulation without emulating a conventional central processing unit.
+
+34. The method of claim 31, wherein the cellular automaton state image implements a virtual processor using persistent propagating structures as information carriers.
+
+35. The method of claim 31, further comprising validating the result by comparing outputs from redundant cellular automaton cores.
+
+## Independent Claim 36: Non-Transitory Medium
+
+36. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors or update circuits, cause performance of operations comprising:
+   receiving a cellular automaton state image encoding an executable computation;
+   storing the cellular automaton state image in a memory array;
+   repeatedly applying a fixed local evolution function to cell states of the cellular automaton state image; and
+   reading one or more designated output regions after one or more applications of the fixed local evolution function to obtain computational output.
+

drafts/figures.md

@@ -0,0 +1,42 @@
+# Suggested Figures
+
+## Figure 1: System Overview
+
+A block diagram showing a host processor, memory array, CA update engine, image loader, output reader, and optional validation module.
+
+## Figure 2: CA Memory Word Packing
+
+A diagram showing a 64-bit memory word containing ten 6-bit CA cell/core states and remaining spare bits for parity, CRC, metadata, or integrity checking.
+
+## Figure 3: Local Evolution Function
+
+A diagram showing a central cell, bounded neighborhood, and transition function `F` producing the next state of the central cell.
+
+## Figure 4: Pull-Based Race-Free Update
+
+A diagram contrasting multi-writer push updates with a pull-based update in which each cell writes only its own next state.
+
+## Figure 5: Symmetry-Preserving Conflict Resolution
+
+A diagram showing multiple incoming neighbor influences collected as a local pattern and mapped to a next state without fixed directional priority.
+
+## Figure 6: Bias-Compensated Orientation Pattern
+
+A diagram showing rows, planes, tiles, or cells assigned different priority orientations according to a balanced repeating pattern.
+
+## Figure 7: State Image As Effective Hardware
+
+A diagram showing different loaded CA images defining different effective machines, such as a virtual processor, particle simulator, or special-purpose accelerator, while the same hardware update rule remains fixed.
+
+## Figure 8: Persistent Propagating Structures
+
+A diagram showing gliders or other localized structures moving through the lattice and interacting at collision or logic regions.
+
+## Figure 9: Output Regions
+
+A diagram showing designated regions of the CA memory read after update cycles to obtain computational output.
+
+## Figure 10: Redundant Or Transformed Core Validation
+
+A diagram showing multiple CA cores executing identical, mirrored, rotated, or transformed versions of a state image, with outputs compared or mapped to a common interpretation.
+

drafts/patent_application.md

@@ -0,0 +1,184 @@
+# Systems and Methods for Executing Memory-Image-Defined Computation on a Cellular Automaton Computing Substrate
+
+## Cross-Reference To Related Applications
+
+[To be completed.]
+
+## Field
+
+The disclosure relates to cellular automata, reconfigurable computing, processing-in-memory, accelerator architectures, nonlinear simulation, reversible or information-conserving computation, and memory-image-defined computational substrates.
+
+## Background
+
+Conventional digital processors execute programs primarily as sequences of instructions interpreted by fixed processor hardware. General-purpose processors provide substantial flexibility, but their performance and energy efficiency may be limited for workloads involving large numbers of local nonlinear interactions, spatial propagation, collision dynamics, particle-like behavior, wave-like behavior, or other computations that are naturally expressed as local evolution over a spatial domain.
+
+Special-purpose accelerators may improve performance for selected workloads, but the hardware behavior of such accelerators is generally fixed after fabrication. Field-programmable gate arrays provide reconfigurability, but reconfiguration may be costly, may require specialized hardware-description flows, and may not provide a native model for computations expressible as local nonlinear dynamics.
+
+Cellular automata provide a model of computation in which cell states evolve according to local transition rules. Certain cellular automata exhibit persistent propagating structures, collision behavior, and universal computation. However, known cellular-automaton computation systems often emphasize theoretical universality, software simulation, or isolated demonstrations of logic, rather than a practical computing substrate in which executable machines and simulation engines are loaded as spatial memory images and evolved by fixed high-speed update circuitry.
+
+There remains a need for a computing architecture in which a fixed local evolution rule is implemented efficiently in hardware while effective processor architectures, accelerators, and nonlinear simulation machines are updated by loading different cellular automaton state images.
+
+## Summary
+
+In one aspect, a computing system comprises a memory array configured to store cell states of a cellular automaton and update circuitry configured to repeatedly apply a fixed local evolution function to the cell states. An executable computation is encoded as a cellular automaton state image loaded into the memory array. The state image may include persistent propagating structures, interaction regions, routing structures, emitter structures, detector structures, register regions, memory-interface regions, and output regions. Computational results are obtained by reading predetermined output regions after one or more update cycles.
+
+In some embodiments, the fixed local evolution function is a protected evolution function `F` operating on compact multi-bit cell states. In some embodiments, each cell state comprises a 6-bit value. Multiple independent cellular automaton cores may be packed into wider memory words, such as ten 6-bit cell states in a 64-bit word with additional bits used for metadata, parity, cyclic redundancy checking, error detection, or other integrity functions.
+
+In some embodiments, the cellular automaton state image defines an effective hardware architecture, such as a virtual processor, special-purpose accelerator, signal-routing fabric, or logic network. Loading a different state image changes the effective hardware behavior without modifying the physical update circuitry that implements the evolution function.
+
+In other embodiments, the cellular automaton state image directly defines a nonlinear simulation engine, such as a particle simulator, radiation transport simulator, plasma wakefield simulator, field propagation engine, collision cascade model, nonlinear wave computation engine, or spatial constraint solver. Such direct image programs may use the native dynamics of the evolution function rather than emulating a conventional sequential processor.
+
+In some embodiments, the update circuitry implements a deterministic pull-based update in which each cell computes its own next state from its current state and a bounded neighborhood, thereby avoiding nondeterministic multi-writer conflicts. Simultaneous neighbor influences may be resolved by a symmetry-preserving transition rule, by producing collision states, or by a deterministic priority orientation distributed across the lattice according to a balanced spatial pattern to compensate directional bias.
+
+In some embodiments, outputs from multiple cellular automaton cores are validated by comparison, parity, cyclic redundancy checking, or execution of mirrored, rotated, coordinate-transformed, or otherwise transformed versions of a state image.
+
+## Brief Description Of The Drawings
+
+Figure 1 illustrates an example computing system comprising a host processor, memory array, image loader, cellular automaton update engine, output reader, and validation module.
+
+Figure 2 illustrates an example packed memory word storing multiple compact cellular automaton cell states and additional integrity bits.
+
+Figure 3 illustrates a local evolution function computing a next state from a central cell and a bounded neighborhood.
+
+Figure 4 illustrates a pull-based race-free cellular automaton update.
+
+Figure 5 illustrates symmetry-preserving conflict resolution in which simultaneous neighbor influences are collected as a local pattern.
+
+Figure 6 illustrates a bias-compensated deterministic orientation pattern distributed across cells, rows, planes, tiles, or cores.
+
+Figure 7 illustrates loading different cellular automaton state images to define different effective hardware architectures or simulation engines.
+
+Figure 8 illustrates persistent propagating structures and interaction regions.
+
+Figure 9 illustrates designated output regions from which computational results are read.
+
+Figure 10 illustrates redundant or transformed cellular automaton cores for validation.
+
+## Detailed Description
+
+### Overview
+
+The disclosed system provides a reconfigurable cellular automaton computing substrate. A physical substrate stores cell states in memory and repeatedly applies a fixed local evolution function `F`. Rather than executing only a conventional sequential instruction stream, the system loads computation as one or more cellular automaton state images. The image evolves under `F`, and computational output is read from designated memory regions.
+
+The physical update hardware may remain unchanged while the effective machine executed by the substrate changes. A first loaded image may define a virtual processor. A second loaded image may define a particle simulator. A third loaded image may define a plasma wakefield simulation engine. A fourth loaded image may define a collision-based logic network or special-purpose accelerator. Thus, the system provides mutable effective hardware on a fixed physical rule engine.
+
+### Cellular Automaton State
+
+The cellular automaton comprises a plurality of cells arranged on a lattice. The lattice may be one-dimensional, two-dimensional, three-dimensional, or higher-dimensional. In a preferred class of embodiments, the lattice is three-dimensional and each cell has a bounded neighborhood, such as axial neighbors, diagonal neighbors, a Moore neighborhood, a von Neumann neighborhood, or another fixed local neighborhood.
+
+Each cell stores a cell state. The cell state may be a compact multi-bit value. In one embodiment, each cell state comprises a 6-bit value, providing 64 possible states. The bits may encode one or more of a core state, cell type, phase, direction, parity, interaction state, collision state, or auxiliary state. The precise interpretation of the bits may be defined by the evolution function `F` and by the image program loaded into the substrate.
+
+In some embodiments, the evolution function `F` is cell-type-count preserving. In some embodiments, `F` conserves one or more quantities associated with cell states. In some embodiments, `F` is information-conserving or reversible. In other embodiments, `F` is deterministic but not fully reversible.
+
+### Fixed Local Evolution Function
+
+The update circuitry applies a fixed local evolution function `F` to compute next cell states. For a cell `c`, the next state may be expressed as:
+
+```text
+next(c) = F(state(c), states(N(c)))
+```
+
+where `N(c)` is a bounded neighborhood of `c`.
+
+The function `F` is local, deterministic, and closed over the cell-state alphabet. In embodiments designed for highly parallel hardware, each cell computes and writes only its own next state. This pull-based update avoids nondeterministic write conflicts that may occur when multiple neighboring cells attempt to write to the same destination cell.
+
+The function `F` may be embodied in combinational logic, a lookup table, microcoded update circuitry, FPGA logic, GPU kernels, SIMD instructions, near-memory update circuitry, processing-in-memory circuitry, or an application-specific integrated circuit.
+
+### Persistent Propagating Structures
+
+In some embodiments, the evolution function `F` supports persistent propagating structures. Such structures may include gliders, localized wave packets, particle-like configurations, or other coherent patterns that propagate through the lattice while preserving recognizable identity or information.
+
+Persistent propagating structures may be used as signals, information carriers, particle analogues, routing elements, timing structures, or components of logic gates. Compared with fragile propagating structures in some cellular automata, the persistent structures contemplated here may be robust under the protected evolution function and may support reliable routing, collision, emission, detection, or computation.
+
+### Image Programs
+
+An image program is a cellular automaton state image configured to perform a computation by evolving under `F`. The image may include initial states, maintained boundary regions, emitter regions, detector regions, interaction regions, routing paths, memory regions, register regions, and output regions.
+
+Image programs may be loaded into the memory array by a host processor, direct memory access engine, image loader, external device, or another subsystem. Once loaded, the update circuitry repeatedly applies `F`. The computation proceeds as the state image evolves. Results may be read from predetermined output regions after a specified number of update cycles, upon satisfaction of a stopping condition, or continuously during evolution.
+
+The image program may define an effective hardware architecture. For example, a state image may define a virtual processor comprising register regions, instruction-processing structures, memory-interface regions, routing paths, control structures, and output regions. The virtual processor may use persistent propagating structures as signals and collision regions as logic or control elements.
+
+Alternatively, the image program may directly define a nonlinear simulation. In such embodiments, the CA evolution itself performs the simulation, and the system need not emulate a conventional processor. The state image may represent particles, fields, emitters, detectors, boundary conditions, media properties, interaction regions, or measurement regions.
+
+### Effective Hardware Updated By Loading Images
+
+The system separates the physical update rule from the effective machine. The physical circuitry implements `F`. The loaded image defines how `F` is used.
+
+Loading a different image may alter the effective hardware architecture without changing the physical update circuitry. For example, after deployment, the same device may be reconfigured from a particle simulation engine to a virtual processor, from a virtual processor to a special-purpose accelerator, or from one accelerator topology to another accelerator topology by replacing the loaded CA state image.
+
+This is distinct from merely loading different data into a conventional processor. In the disclosed system, the loaded image may define the machine structure itself, including signal paths, interaction regions, emitters, detectors, registers, gates, memory interfaces, and output regions.
+
+### Packed Multi-Core Representation
+
+In some embodiments, multiple CA cores are packed into a wider memory word. For example, a 64-bit memory word may store ten 6-bit cell states, leaving four additional bits. The additional bits may be used for parity, cyclic redundancy checking, error detection, metadata, phase information, boundary tags, addressing information, or other integrity or control information.
+
+The packed representation may enable parallel execution of multiple independent CA cores. The cores may execute identical images, different images, redundant images, mirrored images, rotated images, coordinate-transformed images, or images representing different simulation parameters.
+
+### Validation And Redundancy
+
+The system may include validation circuitry or software configured to compare outputs from multiple CA cores. Redundant cores may execute identical images. Alternatively, transformed cores may execute mirrored, rotated, coordinate-inverted, or otherwise transformed versions of a state image. Outputs may be mapped to a common interpretation and compared.
+
+Validation may include equality checks, threshold comparisons, parity checks, CRC checks, statistical checks, conservation-law checks, or domain-specific output checks. Such validation may detect hardware faults, memory corruption, update faults, radiation-induced errors, or divergent computation.
+
+### Conflict Resolution
+
+Parallel CA updates may encounter simultaneous neighbor influences. A push-based update in which cells attempt to write to neighbors may create races or nondeterministic multi-writer conflicts. The disclosed system may instead use pull-based updates in which each cell reads its neighborhood and computes only its own next state.
+
+In some embodiments, `F` resolves simultaneous influences by collecting all relevant neighbor influences into a local pattern and mapping that local pattern to a next state. The mapping may avoid selecting a winning neighbor according to a fixed global priority direction.
+
+In some embodiments, `F` is equivariant under selected lattice transformations. For a selected transformation `T`, the function may satisfy:
+
+```text
+F(T(neighborhood)) = T(F(neighborhood))
+```
+
+This property may reduce artificial directional bias and may support mirrored or transformed redundancy.
+
+In other embodiments, deterministic local priority is used, but the priority orientation varies across the lattice. For example, cells, rows, planes, tiles, or cores may be assigned orientation classes corresponding to different priority directions. The orientation classes may be distributed according to a balanced pattern such that no lattice direction is globally preferred. The orientation class may be hardcoded in ASIC layout, stored in metadata, derived from low-order address bits, or determined by a repeating supercell.
+
+### Native Nonlinear Computation
+
+The CA substrate may be particularly useful for computations naturally expressible as local nonlinear evolution. In such workloads, the CA tick itself performs useful computation. Unlike conventional particle or field simulation approaches that calculate interactions explicitly as pairwise or matrix operations, the disclosed substrate may represent interacting structures within the state image and allow interactions to arise through repeated local application of `F`.
+
+For a fixed lattice region and representable density, the update cost may be determined primarily by the number of cells updated rather than by the number of pairwise interactions represented within the image. This may provide advantages for dense local dynamics, propagation, collision, or field-like computation.
+
+Example native workloads include particle simulation, radiation transport, plasma wakefield simulation, nonlinear field propagation, wave dynamics, collision cascades, cellular materials, spatial Bayesian propagation, event detection, and local constraint solving.
+
+### Virtual Processor Embodiment
+
+In one embodiment, the loaded state image comprises a virtual processor. The virtual processor may include register regions, control regions, memory access structures, instruction decoding structures, routing paths, clocking or phase structures, and output regions. Persistent propagating structures may function as signals. Interactions between propagating structures may implement logic, branching, memory access, synchronization, or control flow.
+
+The virtual processor embodiment demonstrates that the substrate may host general-purpose computation. However, the substrate is not limited to virtual processor images. Direct simulation images and special-purpose accelerator images may use the CA dynamics more directly and may avoid overhead associated with emulating conventional instruction execution.
+
+### Hardware Implementations
+
+The update circuitry may be implemented using one or more of an ASIC, FPGA, GPU, CPU SIMD engine, vector processor, near-memory processor, processing-in-memory array, memory controller, or dedicated co-processor. In an ASIC embodiment, the update circuitry may be configured to read fixed neighborhoods, compute next states according to `F`, and write next states at high speed. Double buffering, phase buffering, tile buffering, streaming update, or other memory-management techniques may be used.
+
+The memory array may include SRAM, DRAM, embedded DRAM, high-bandwidth memory, stacked memory, nonvolatile memory, or another storage medium capable of storing CA cell states. The update circuitry may be located adjacent to, integrated with, or distributed within the memory array.
+
+## Example Embodiments
+
+### Example 1: Reconfigurable CA Processor
+
+A host loads a state image defining a virtual processor into a high-speed memory array. The update engine applies `F` for a predetermined number of ticks. The virtual processor writes results to designated output regions. The host reads the output regions and may load a different image to change the effective processor architecture.
+
+### Example 2: Particle Transport Image
+
+A state image encodes particle-like structures, emitters, detectors, and interaction regions. The update engine applies `F`, causing persistent structures to propagate and interact. Detector regions accumulate output values corresponding to transport, scattering, absorption, or arrival events.
+
+### Example 3: Plasma Wakefield Image
+
+A state image encodes beam-like structures, field-like regions, boundary conditions, and measurement zones. Applying `F` evolves the image to approximate or compute nonlinear propagation and wakefield interactions. Output regions store measurements of field intensity, particle arrival, or other quantities.
+
+### Example 4: Bias-Compensated ASIC Update
+
+Each cell has an orientation class derived from low-order address bits. The orientation class determines a deterministic priority order for local conflict resolution. A repeating supercell assigns equal numbers of orientation classes corresponding to opposing and orthogonal lattice directions. The resulting update remains deterministic and hardware-simple while reducing global directional drift.
+
+### Example 5: Mirrored Core Validation
+
+Ten 6-bit CA cores are packed into a 64-bit memory word. Several cores execute mirrored or rotated versions of the same state image. Output regions are transformed back to a common coordinate frame and compared. Divergence indicates a possible memory error, hardware fault, or invalid computation.
+
+## Claims
+
+[See `claims.md` for the working claim set.]
+

notes/glossary.md

@@ -0,0 +1,38 @@
+# Glossary
+
+**Cellular automaton / CA**  
+A discrete dynamical system comprising cells having states that are updated according to a local transition rule or evolution function.
+
+**Evolution function `F`**  
+The protected local transition function applied to a cell and a bounded neighborhood to compute a next state.
+
+**Cell state**  
+The state value stored for a CA cell. In the current contemplated embodiment, each cell may be represented by a compact multi-bit state, for example a 6-bit state.
+
+**State image / image program**  
+An initial, maintained, or loaded spatial configuration of CA cell states that performs computation by evolving under `F`.
+
+**Memory-image-defined computation**  
+Computation in which the effective machine or program is encoded in a CA state image rather than in a conventional sequential instruction stream.
+
+**Persistent propagating structure**  
+A localized CA structure, such as a glider, that propagates through the lattice while preserving recognizable identity or information.
+
+**Interaction region**  
+A spatial region of a CA image configured so that incoming propagating structures interact to perform logic, routing, detection, emission, transformation, or simulation behavior.
+
+**Output region**  
+A predetermined memory region read after one or more CA update cycles to obtain computational output.
+
+**Effective hardware architecture**  
+The logical processor, accelerator, simulation engine, or computation fabric defined by a loaded CA image, as distinguished from the fixed physical update circuitry.
+
+**Pull-based update**  
+A CA update method in which each cell computes its own next state from its current state and neighboring states, thereby avoiding multi-writer conflicts.
+
+**Symmetry-preserving conflict resolution**  
+Conflict handling in which simultaneous neighbor influences are resolved by a rule that is equivariant under selected lattice rotations, reflections, or coordinate transformations.
+
+**Bias-compensated deterministic update**  
+Conflict handling in which deterministic local priority orientations vary across cells, rows, planes, tiles, or cores according to a balanced pattern so that no lattice direction is globally preferred.
+

notes/invention_disclosure.md

@@ -0,0 +1,101 @@
+# Invention Disclosure Notes
+
+## Core Concept
+
+The invention is a programmable cellular automaton computing substrate. A fixed hardware substrate repeatedly applies a specific local evolution function `F` to cell states stored in memory. Programs are loaded as spatial CA state images. The loaded image defines the effective computational machine.
+
+In short:
+
+**The physical update hardware is fixed; the effective machine is loaded.**
+
+## Protected Technical Center
+
+The strongest protected center is the combination of:
+
+- a specific evolution function `F`;
+- compact multi-bit CA cell states, currently contemplated as 6-bit states;
+- hardware or near-memory update circuitry implementing `F`;
+- packed representation of multiple CA cores in wider memory words;
+- deterministic race-free local updates;
+- optional symmetry-preserving or bias-compensated conflict resolution;
+- memory-image-defined computation;
+- output regions, register regions, emitter regions, detector regions, and interaction regions;
+- validation, redundancy, mirroring, coordinate transformation, or CRC/integrity bits across independent cores;
+- use of persistent propagating structures such as gliders for information transport, routing, and logic.
+
+## Invention Family
+
+### Branch 1: Core Substrate
+
+Protects the cellular automaton substrate itself:
+
+- the rule `F`;
+- cell encoding;
+- neighborhood definition;
+- update circuitry;
+- packed memory representation;
+- multi-core execution;
+- integrity and redundancy mechanisms;
+- conflict resolution without nondeterministic write races.
+
+### Branch 2: Reconfigurable Architecture Images
+
+Protects loaded images that define effective hardware:
+
+- virtual processors;
+- register regions;
+- instruction-processing structures;
+- memory interfaces;
+- glider-based logic;
+- routing networks;
+- special-purpose accelerators;
+- replaceable post-deployment architectures.
+
+### Branch 3: Native Nonlinear Simulation Images
+
+Protects direct image programs that use the native CA dynamics:
+
+- particle simulation;
+- radiation transport;
+- plasma wakefield simulation;
+- field propagation;
+- collision cascades;
+- nonlinear wave computation;
+- spatial constraint solving.
+
+## Why Not Lead With A Virtual CPU
+
+A virtual CPU is useful as a proof of expressiveness or universality, but it should not be the headline. A conventional CPU is highly optimized for serial control flow, cache hierarchy, branch prediction, register renaming, pipelining, and vector operations. A CA virtual CPU may pay substantial overhead for spatial signal routing, synchronization, glider travel time, and memory access.
+
+The commercially stronger framing is that the CA substrate natively performs spatial, nonlinear, massively parallel local computation. Some image programs may define a virtual CPU, but other image programs directly implement simulation or accelerator behavior without building an ALU or instruction-fetch loop.
+
+## Candidate Novel Phrases
+
+- memory-image-defined computation;
+- state-image-defined processor architecture;
+- programmable nonlinear computing fabric;
+- reconfigurable cellular automaton computing substrate;
+- race-free pull-based cellular automaton transition function;
+- symmetry-preserving local conflict resolution;
+- bias-compensated deterministic update tiling;
+- effective hardware updated by loading a CA image;
+- fixed physical rule, mutable logical machine.
+
+## Open Technical Details To Fill
+
+1. Exact definition of `F`.
+2. Cell bit layout, including whether 6 bits are divided into core state, phase, direction, parity, or auxiliary state.
+3. Neighborhood used by `F`, such as 6 axial neighbors, 26 Moore neighbors in 3D, or another bounded neighborhood.
+4. Whether `F` is reversible, information-conserving, or merely cell-type-count preserving.
+5. Exact conserved quantities.
+6. Examples of persistent gliders or other propagating structures.
+7. Example collision rules or interaction geometries.
+8. Details of packed 64-bit layout, including ten 6-bit cores plus spare bits.
+9. Whether spare bits are used for CRC, parity, error correction, phase, tags, or metadata.
+10. Whether conflict resolution is fully symmetric, address-derived, row-derived, tile-derived, or core-derived.
+11. Example output-region read protocol.
+12. Example image program for a particle simulator.
+13. Example image program for a virtual processor.
+14. Example image program for plasma wakefield or radiation transport.
+15. Hardware architecture: ASIC, FPGA, GPU, CPU SIMD, near-memory logic, or processing-in-memory.
+