Local update architecture

A local update architecture is a system design principle in which changes to state are applied only within a bounded neighborhood of the event that triggered them, rather than propagated globally across the entire system. The principle is the engineering counterpart to the physical fact of local causation: effects in the world propagate through space at finite speed, and a representation scheme that respects this structure avoids the combinatorial explosion that plagues global-update formalisms.

Local update architectures are the practical dissolution of the Frame Problem in engineering. Where the original formulation asked how to represent what does not change within a globally-scoped logical system, local update architectures sidestep the question entirely by maintaining only partial, neighborhood-bound state and updating it incrementally. The cost is not eliminated — it is relocated from runtime computation to design-time decisions about what constitutes a neighborhood.

Core Principles

The defining feature of a local update architecture is bounded scope: every update operation has a predetermined spatial, temporal, or logical boundary beyond which effects do not propagate. This boundary is not an approximation or a heuristic. It is a structural property of the architecture, encoded in the system's topology.

Spatial locality is the most intuitive form. In a simultaneous localization and mapping system, when a robot moves through a corridor, only the map cells within sensor range are updated. Cells in distant rooms are not touched. The robot does not face the Frame Problem because it never attempts to maintain global consistency — it maintains local consistency, and local consistency is tractable.

Temporal locality applies in stream processing systems and event-sourced architectures. When an event occurs, only the state derived from that event and its immediate predecessors is recomputed. Historical state that is not on the event's causal path remains unchanged. This is the principle behind event sourcing and CQRS: the system stores events, not state, and reconstructs state on demand within bounded time windows.

Logical locality is the most abstract form. In distributed databases that use conflict-free replicated data types (CRDTs), updates are applied locally at each replica and merged with other replicas through commutative operations. The merge is local to the data structure's semantics — a counter increments, a set adds an element — and does not require global coordination. The system's consistency is eventual, not immediate, and the boundary of consistency is the data structure itself.

The Frame Problem Dissolved

The classical Frame Problem asks: given an action, how do you represent all the facts that do not change? In a local update architecture, the answer is trivial: the facts outside the update boundary do not change because the architecture does not represent them at all.

This is not a trick. It is a structural mismatch resolved. The Frame Problem arose because situation calculus treated the world as a list of globally-scoped facts. Physical causation does not work this way. A local update architecture matches its representation to the causal topology of the world it represents. When the representation topology matches the causal topology, the Frame Problem vanishes.

The dissolution is not free. The architecture pays a price in long-range dependency blindness. A system that updates locally cannot, by design, detect causal chains that propagate beyond its update boundary. A SLAM robot will not know that a policy change in Washington has altered traffic patterns in its city. A distributed database with local merge semantics will not detect global constraint violations until they manifest as local inconsistencies. The Frame Problem is not solved; it is traded for bounded incompleteness.

Examples

Robotics: SLAM systems, reactive control architectures, and behavior-based robotics all use local update architectures. The robot's world-model is not a global map but a collection of local maps, each consistent within its own frame of reference and loosely coupled to others through transformation matrices.

Distributed systems: Gossip protocols propagate updates through random pairwise exchanges. No node maintains global state; each node maintains a local approximation that converges to global consistency over time. The convergence is asymptotic, not guaranteed, and the rate depends on network topology.

Databases: Event-sourced systems store immutable events and derive state through projections. Each projection is a local update over a bounded event stream. The system does not update a global database state; it appends events and recomputes views on demand.

Biology: Neural networks in the brain update synaptic weights through local Hebbian rules. A synapse strengthens or weakens based on the correlation of pre- and post-synaptic activity in its immediate neighborhood. There is no global coordinator that updates all synapses after each experience. The brain is a local update architecture par excellence, and its capacity for coherent behavior despite local learning rules is one of the central puzzles of neuroscience.

The Design-Time Frame Problem

Local update architectures dissolve the runtime Frame Problem but create a design-time counterpart. The engineer must decide, before the system operates, what the update boundary should be. This decision requires knowledge of the causal topology of the environment — knowledge that is often unavailable or incomplete.

Consider a content moderation system for a social network. Should an update to a user's trust score propagate to their followers? To their followers' followers? To users who have interacted with their content? The boundary is not given by physics; it is a design choice with political consequences. Local update architectures do not eliminate the problem of relevance. They make it explicit, visible, and politically charged.

The deeper claim: the Frame Problem is the price of world-modeling, and local update architectures pay it upfront in design rather than continuously at runtime. This is a genuine savings — design-time reasoning is done once, runtime reasoning is done continuously. But the savings is only available when the environment's causal topology is stable enough to be anticipated. In open-ended environments, where causal structures are novel and unpredictable, the design-time Frame Problem is as hard as the runtime one.