Frame Problem

Prime #

870

Origin domain

Computer Science & Software Engineering

Subdomain

artificial intelligence → Computer Science & Software Engineering

Core Idea

After a change alters part of a represented world, an agent must bound what else now needs updating and what persists by default — without re-checking everything. The hard part is bounding the cloud of indirect consequences, which requires a closure rule or a representation where most facts are invariant under most actions.

How would you explain it like I'm…

What Else Changed?

When you knock over one block in your tower, you know the other blocks far away didn't move. The hard part for a robot is figuring out which things stayed the same and which things changed. Checking every single toy in the whole room after one move would take forever.

The Ripple Puzzle

When you change one thing in the world, you have to figure out what else that change affected. Usually the change itself is easy to see, but the hard part is the ripples. If you checked every single fact in the world after every action, you'd never finish. So you need a smart rule that says 'almost everything stays the same' and only points at the few things that actually need a second look. The Frame Problem is the puzzle of drawing that line in the right place.

Bounding the Consequences

Suppose a system models the world as a big list of facts, and then something happens. The direct effect of the event is usually given, but the system still has to decide which other facts changed and which stayed put. Re-checking every fact after every action is impossibly slow, so the system needs a closure rule that lets most facts persist 'for free' and only flags the small set that truly need re-deriving. The Frame Problem is the challenge of bounding that cloud of indirect consequences. Get the boundary too loose and you carry stale, wrong facts; too tight and you waste effort re-checking things that never moved. Crucially, where the boundary belongs depends on the representation and the purpose, so 'the consequences' of an action are never just objectively handed to you.

 

The Frame Problem is the structural challenge of bounding the consequences of a change in a represented world. After an event alters part of the representation, an agent must decide what else now needs updating and what can be left untouched. The genuinely hard part is not deducing the direct effect, which is typically declared, but bounding the cloud of indirect ramifications without re-checking every fact, which is combinatorially infeasible. After a change, the state partitions into three regions: the direct effects, the frame (the large set of facts that persist by default), and the relevant ramifications (the small set that actually need re-derivation, plus a residual set of newly uncertain facts). A solution requires either an explicit closure rule, such as a frame axiom or a non-monotonic default, or a representational stance that makes most facts invariant under most actions so they fall outside the frame automatically. The closure rule can fail in two directions: too loose propagates stale data and silent errors, while too tight loses the efficiency benefit and produces churn. And the frame is always relative to a representation and a purpose, so the same physical change has a tight frame for an engineer and a broad one for an accountant.

Broad Use

• Artificial intelligence: The McCarthy–Hayes formulation — which fluents change, persist, or become unknown — answered by frame axioms, the closed-world assumption, and non-monotonic logics.
• Law: When a court rules or a statute is amended, stare decisis and distinguishing bound which prior holdings still stand.
• Project management: A scope change invalidates some dependent tasks; dependency graphs and critical-chain tools bound what must be re-examined.
• Software systems: After state changes, build-system DAGs and cache invalidation decide which derived artifacts are stale.
• Cognitive science: Dennett's robot must wheel a wagon out without freezing on every consequence or ignoring the one that matters.
• Scientific revision: When a theory is revised, which prior results stand, need re-derivation, or become uninterpretable?

Clarity

It pulls apart three things that collapse into "consequences" — the direct effect, the frame (what persists by default), and the relevant ramifications — sharpening one diagnostic question: do you have an explicit account of what persists?

Manages Complexity

It manages complexity by shifting the default to "nothing else changed," so the agent audits only a small candidate set — the structural reason build systems, caches, diffs, and change-impact analysis work in practice.

Abstract Reasoning

It invites a three-valued decomposition of any change — what changed, what holds, what is now unknown — and foregrounds whose frame, since persistence is always judged from a representation and a purpose.

Knowledge Transfer

• Build systems to law: Explicit dependency graphs and closure-by-default rules appear as DAGs in software and stare-decisis-plus-distinguishing in law.
• AI to engineering: Re-derivation triggers travel as cache-invalidation keys, reactive dependencies, and change-control reviews.
• Across domains: A renamed function and an amended privacy statute run the same project — bound the relevance cloud without re-reading everything.

Example

A build system rebuilds only the transitive reverse-dependencies of an edited file via a DAG-plus-timestamp closure rule — but a missing dependency edge (a too-loose frame) leaves a stale object and the notorious "works after a clean rebuild" bug, fixed exactly by making the implicit frame explicit.

Not to Be Confused With

• Frame Problem is not Framing because it draws a persistence boundary after an update, whereas framing selects which aspects of a fixed situation to foreground — the shared word "frame" hides opposite concerns.
• Frame Problem is not Cognitive Reframing because it maintains coherence within one representation, whereas reframing deliberately switches to a new interpretive lens.
• Frame Problem is not a Markov Process because it is the general challenge of bounding ramifications, for which the Markov assumption is one (often too-strong) closure rule.