Frame Problem¶

Prime #: 870
Origin domain: Computer Science & Software Engineering
Subdomain: artificial intelligence → Computer Science & Software Engineering

Core Idea¶

The frame problem is the structural challenge of bounding the consequences of a change. After an event or action alters some part of a represented world, an agent must decide what else in its representation now needs updating and what can be safely left alone. The hard part is not deducing the direct effect — that is usually given — but bounding the cloud of indirect consequences without re-checking every fact. A solution requires either an explicit closure rule (a frame axiom, a non-monotonic default) or a representational stance that makes most of the world's facts invariant under most actions, so they fall outside the relevant frame for free. The essential commitment is that change without a closure rule is intractable: either the agent re-checks everything (combinatorially infeasible) or it assumes too much persists (silent breakage from missed indirect effects).

Every instance partitions the state into three regions after a change event. There are the direct effects — the immediate, declared change. There is the frame — the typically large set of facts that persist by default and need not be touched. And there are the relevant ramifications — the typically small set that do need re-derivation, plus a residual set whose status has become uncertain. The closure rule is the structural piece that draws these boundaries, and it can fail in two directions: a frame that is too loose (assumes too much persists) propagates stale data and silent errors, while a frame that is too tight (re-derives too much) loses the efficiency benefit and produces churn. The frame is always relative to a representation and a purpose — the same physical change has a tight frame for an engineer and a broad one for an accountant — so "the consequences" of an action are never objectively given.

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.

Structural Signature¶

the represented state — the change event declaring a direct effect — the frame of facts persisting by default — the relevant ramifications needing re-derivation — the closure rule drawing the boundaries — the frame-relativity invariant (persistence is judged from a representation and a purpose)

The pattern is present when the following components are jointly in play:

The represented state (the large fact set). A representation of a world holding many facts, most of which any given change leaves untouched.
The change event (the declared direct effect). An action or event that alters some part of the representation; its immediate, declared effect is usually given. The hard part is bounding what else now follows.
The frame (the default-persistent region). The typically large set of facts that persist by default and need not be re-checked. Treating this region as stable is what makes reasoning tractable.
The relevant-ramifications region (the re-derivation set). The typically small set that genuinely needs updating, plus a residual set whose status has become uncertain rather than false.
The closure rule (the boundary-drawer). An explicit account — frame axiom, non-monotonic default, dependency graph, invalidation key — that partitions state into persistent and re-derivable. It can fail too loose (stale data, silent error) or too tight (churn, lost efficiency).
The frame-relativity invariant. The partition is always relative to a representation and a purpose; the same physical change has a tight frame for one standpoint and a broad one for another, so "the consequences" are never objectively given.

Composed, these convert open-ended re-evaluation into a bounded one: a closure rule shifts the default to "nothing else changed," so only a small candidate set is audited — provided the rule's tightness matches the domain's real persistence structure.

What It Is Not¶

Not framing. framing selects which aspects of a situation to foreground, shaping how a fixed situation is interpreted; the frame problem is about bounding which facts must be re-derived after a change. One chooses a lens on a static scene; the other draws a persistence boundary after an update. The shared word "frame" hides opposite concerns.
Not cognitive reframing. cognitive_reframing deliberately adopts a new interpretive lens; the frame problem is about maintaining coherence within a representation under incremental change. Reframing switches the frame; the frame problem maintains relevance-closure inside one.
Not a Markov process. markov_process is a formal model where the next state depends only on the current state; the frame problem is the general challenge of bounding ramifications after a change, which the Markov assumption is one (often too-strong) closure rule for.
Not presentism. presentism is the historiographic error of judging the past by present standards; the frame problem concerns which facts persist after an event in a represented world, carrying no temporal-bias judgment.
Not belief formation. belief_formation and bayesian_updating concern how an agent acquires or revises beliefs from evidence; the frame problem concerns which existing facts must be re-derived after a declared change. One forms beliefs; the other bounds their re-evaluation.
Not deep time. deep_time is the apprehension of vast temporal scales; the frame problem is scale-neutral, concerning relevance-closure after any update regardless of horizon.
Common misclassification. Treating "I applied the change" as "I handled the change." The direct effect is easy and visible; the hard, open-ended part is bounding the transitive closure of indirect ramifications. Catch it by separating "what did I directly alter?" from "what depends on it?" — if the process stops at the first, the ramification cloud is unmanaged.

Broad Use¶

Artificial intelligence. The original McCarthy–Hayes formulation: when an action applies to a state, which fluents change, which persist, which become unknown? Frame axioms, the closed-world assumption, successor-state axioms, and non-monotonic default logics are the answers.
Law. When a court rules, a statute is amended, or a contract is breached, which downstream holdings, clauses, and cases still stand? Precedent and the doctrine of distinguishing function as a relevance-closure mechanism: most prior holdings persist by default; only those touching the same fact-pattern are re-examined.
Project planning and change management. A scope change, a delivery slip, or a key departure invalidates some dependent tasks, estimates, and commitments; dependency graphs and critical-chain tools exist to bound what must be re-examined.
Software systems. After a file or piece of state changes, which derived artifacts are stale? Build-system DAGs make persistence explicit; reactive UIs and caches make it implicit. Cache invalidation is the frame problem at the dataflow layer.
Cognitive science and philosophy of mind. Dennett's robot must wheel a wagon out of a room without freezing on every consequence or ignoring the consequence that matters; real cognition presupposes apparatus that flags only some facts as worth reconsidering.
Scientific revision. When a theory is revised, which prior results still stand, which need re-derivation, which become uninterpretable?
Editorial and documentation work. When a fact or definition changes in one place, which other passages, footnotes, and cross-references now need editing?

Clarity¶

The phrase pulls apart three things that otherwise collapse into a vague notion of "consequences": the direct effect (the declared change), the frame (what persists by default), and the relevant ramifications (the small set that must be re-derived, plus the larger set now uncertain). Naming this partition sharpens a single diagnostic question: do you have an explicit account of what persists? If not, the system is committed by default to either combinatorial re-checking or silent breakage. The clarity gain lies in surfacing a missing structural piece — the closure rule — that practitioners routinely leave implicit.

The framing also makes frame relativity visible, which counters the illusion that an action's consequences are objectively fixed. Because every frame is relative to a representation and a purpose, the same change has a tight frame in one accounting of the world and a broad one in another, and disputes about "what follows" are often disputes about whose frame is in force. Recognizing this turns an argument about consequences into an inspectable question about closure rules and their scope.

Manages Complexity¶

The frame problem manages complexity by shifting the default. Without a frame, every action has potentially unbounded consequences and reasoning is exponential. With a frame, the default becomes "nothing else changed," and the agent need only audit a small candidate set of possibly-affected facts. This is the structural reason build systems, cache layers, version-control diffs, change-impact analysis, and three-way merge all work in practice: each encodes a frame assumption that makes the residual work tractable. The closure rule converts an open-ended re-evaluation into a bounded one.

The same structure explains why frame failures are so painful. A too-loose frame propagates stale data and silent errors; a too-tight frame loses the efficiency and may produce churn. Tuning the frame — neither so permissive that indirect effects leak through nor so conservative that it re-derives the world — is itself a recurring engineering and design problem. The management of complexity is therefore not the closure rule alone but the ongoing calibration of its tightness against the real persistence structure of the domain.

Abstract Reasoning¶

The frame problem invites a clean three-valued decomposition of any change event: what changed, what holds, what is now unknown. This partition generalizes the notion of "consequence" beyond classical entailment. Non-monotonic logics — default logic, circumscription, autoepistemic logic — were developed precisely to formalize "facts persist unless contradicted," and belief revision (the minimal-revision postulates) is a sibling formalism responding to the same structural problem of bounded ramification: given a new fact, change as little as possible. Both are families of closure rules over the same underlying partition.

The abstraction also foregrounds whose frame. Because a frame is always relative to a representation and a purpose, reasoning about change must specify the standpoint from which persistence is judged. Reasoning at this level asks, of any update: what is the declared direct effect, what closure rule governs persistence here, which candidates require re-derivation, and which facts have merely become uncertain rather than false? This distinguishes the frame problem from neighbors that otherwise blur with it — from the space of reachable states (which says where one can go, not what comes along), from cognitive reframing (choosing a new lens, rather than maintaining coherence within one), and from general relevance (relevance-to-update under an event, not relevance-to-attention or relevance-to-decision).

Knowledge Transfer¶

Solutions discovered in one domain transfer as identifiable structural moves, carried by stable role mappings: the state representation holds the large fact set; the change event declares a small direct effect; the frame is the persisting remainder; the closure rule decides what persists; and the residual candidates and uncertainty set are the small regions needing re-derivation or re-investigation. With these roles fixed, an engineer, a lawyer, and a project manager can recognize one another's problem.

Four families of moves travel especially cleanly. Explicit dependency graphs — build systems, project plans, spreadsheets, scientific reasoning — make the persistence relation legible so impact analysis is bounded. Closure-by-default rules — "nothing else changed unless the change touches X" — appear as non-monotonic logics in AI, as settled-matter and precedent doctrines in law, and as delta documentation in engineering change orders. Re-derivation triggers — cache-invalidation keys, reactive dependencies, change-control reviews — mark the conditions under which the frame closure fails and re-evaluation is forced. And frame audits — post-incident reviews, refactor checklists, legal harmonization passes — periodically question whether the implicit frame still matches reality. The unifying transferable intervention is one move: when a system feels brittle around change, ask whether the frame is unstated or mis-specified, then make it explicit. A government passing a data-privacy statute (one paragraph changed, but contracts, policies, vendor agreements, and training programs to be audited) and a developer renaming a function (one line changed, but callers, tests, docs, and downstream consumers to be checked) are running the same project: bound the relevance cloud without re-reading everything. The transfer is robust because the strip-the-jargon residue — after a change, which facts persist by default and which must be re-derived — survives into any domain where a represented world is updated incrementally.

Examples¶

Formal/abstract¶

A software build system is the worked instance where the closure rule is fully explicit and inspectable. The represented state is the dependency DAG: source files, headers, intermediate objects, the final binary, with edges declaring "Y is derived from X." A developer edits one source file — the change event with a small direct effect. The frame is the large set of artifacts the DAG declares independent of that file: they persist by default and are not rebuilt. The relevant-ramifications region is exactly the transitive closure of the edited file's reverse dependencies — the object file compiled from it, anything that links that object, the binary. The closure rule is the DAG-plus-timestamp comparison: rebuild a node iff one of its inputs is newer. This converts an open-ended "what is now stale?" into a bounded graph traversal — the structural reason build systems work at all. The prime predicts both failure directions precisely. A too-loose frame — a missing dependency edge (a header used but not declared) — leaves a stale object in place, producing the notorious "works after a clean rebuild" bug: silent breakage from an indirect effect that fell outside the frame. A too-tight frame — a phony timestamp or an over-broad glob that marks everything dirty — rebuilds the world on every edit, losing the efficiency entirely. The frame-relativity invariant shows up as the distinction between a debug build's dependency graph and a release build's: the same source edit has different ramification sets under different build configurations. The intervention the prime names — "make the implicit frame explicit" — is exactly the fix for flaky incremental builds: declare the missing dependency edges.

Mapped back: The dependency DAG is the represented state, a source edit is the change event, the unrebuilt artifacts are the frame, the reverse-dependency closure is the relevant ramifications, the timestamp rule is the closure rule, and a missing edge is the too-loose frame that propagates stale data.

Applied/industry¶

Legal precedent and legislative amendment instantiate the same relevance-closure structure in a human-institutional substrate. When a court issues a ruling — the change event — the entire body of prior holdings is the represented state, and the legal system cannot afford to re-examine every precedent. The closure rule is the doctrine of stare decisis plus distinguishing: most prior holdings persist by default (the frame), and only those touching the same fact-pattern fall into the relevant-ramifications region that must be re-examined or re-derived. A court "distinguishes" a case precisely to argue that a given precedent lies outside the frame of the present change — a direct dispute over where the closure boundary falls. The frame-relativity invariant is vivid here: the same ruling has a tight frame for a narrow procedural question and a broad one for a constitutional principle, so litigants genuinely argue about whose frame is in force. The legislative parallel: a government amends one clause of a data-privacy statute — one paragraph changed — but the relevant ramifications spread to vendor contracts, internal policies, consent forms, and training programs, each of which must be audited while the bulk of the legal code persists by default. The prime's prescribed intervention — a frame audit, a deliberate harmonization pass — is exactly what a general counsel runs after such an amendment: bound the cloud of affected documents without re-reading the entire corpus. A too-loose frame (assuming a contract clause is unaffected when it silently is) propagates legal exposure; a too-tight frame (re-papering every agreement on any change) produces paralyzing churn.

Mapped back: The body of law is the represented state, a ruling or amendment is the change event, untouched precedents and statutes are the frame, the same-fact-pattern cases and dependent contracts are the relevant ramifications, and stare-decisis-plus-distinguishing is the closure rule whose scope litigants contest.

Structural Tensions¶

T1 — Too-Loose versus Too-Tight Frame (sign of error). A closure rule fails in two opposite directions: too loose and stale data propagates as silent breakage from missed indirect effects; too tight and it re-derives the world, losing the efficiency it existed to provide. The error has a sign, and the two failures have opposite remedies — tightening fixes one and causes the other. The failure mode is tuning toward whichever error last hurt and oscillating, or assuming any frame is better than none. Diagnostic: ask which direction your last failure pointed — a "works after clean rebuild" bug is too-loose; paralyzing churn on every edit is too-tight — and calibrate against the domain's real persistence structure, not against the most recent pain.

T2 — Tractability versus Completeness (scalar). The frame buys tractability by shifting the default to "nothing else changed," which is exactly the assumption that lets indirect effects slip through uncaught. The combinatorial saving and the soundness risk are the same move viewed from two sides. The failure mode is enjoying fast incremental updates while a class of ramifications silently falls outside the audited candidate set. Diagnostic: ask what the frame assumes persists that could have changed through an undeclared path; the facts you never re-check are precisely where a too-aggressive efficiency gain hides its cost.

T3 — Declared Direct Effect versus Ramification Cloud (scopal). The direct effect is usually given and easy; the hard, open-ended part is bounding the cloud of indirect consequences. Effort and attention flow to the declared change because it is visible, while the ramifications — the actual difficulty — go under-examined. The failure mode is treating "I applied the change" as "I handled the change," declaring done at the direct effect and leaving the reverse-dependency closure unaudited. Diagnostic: separate "what did I directly alter?" from "what is the transitive closure of what depends on it?"; if your change process stops at the first, the ramification cloud is unmanaged.

T4 — Persistent versus Now-Uncertain (three-valued partition). Naive treatments split the world into changed and unchanged, but the partition is three-valued: a residual set becomes uncertain rather than false — neither safely persistent nor known to need re-derivation. Collapsing uncertain into persistent is a too-loose frame; collapsing it into re-derive is a too-tight one. The failure mode is binary thinking that has no slot for "status now unknown," so genuinely uncertain facts get silently filed as stable. Diagnostic: after a change, ask not only "what changed and what held?" but "what has become unknown?"; a closure rule with no uncertainty region is hiding its hardest cases in one of the other two.

T5 — Whose Frame (relativity/standpoint). Persistence is never objectively given; it is judged from a representation and a purpose, so the same change has a tight frame for one standpoint and a broad one for another. Disputes about "what follows" are often disputes about whose frame is in force, masquerading as factual disagreement. The failure mode is asserting "the consequences of this change are X" as if standpoint-free, and talking past someone whose representation draws the boundary elsewhere. Diagnostic: when parties disagree about ramifications, ask each from what representation and for what purpose they judge persistence; the argument is usually about closure scope, not about the facts.

T6 — Static Closure Rule versus Drifting Domain (temporal). A frame that correctly matched the domain's persistence structure when it was written silently decays as the domain changes — new dependencies appear, old invariants lapse — so a once-sound closure rule becomes too loose without anyone editing it. The rule is static; the persistence structure it models is not. The failure mode is trusting an aging implicit frame (an undeclared build dependency added years ago, a legal harmonization pass never re-run) long after reality drifted out from under it. Diagnostic: schedule frame audits that re-ask whether the implicit closure still matches the world; a closure rule that has never been re-examined is assumed-correct, not known-correct.

Structural–Framed Character¶

The frame problem sits on the structural side of the structural–framed spectrum, with a mixed-structural label and a low aggregate of 0.3 — a medium-neutral relevance-closure pattern that wears some AI/logic vocabulary at its origin. Two diagnostics read fully structural and three sit at the mid-point, which is what places it just off the pole rather than at it.

Evaluative weight and human-practice-boundedness both score 0.0. Bounding which facts persist after a change and which must be re-derived carries no approval or disapproval — a closure rule is judged tight or loose, not good or bad. And the pattern is not human-practice bound: it runs in fully mechanical substrates, most cleanly in a software build system's dependency DAG and timestamp rule, in cache invalidation, and in reactive UI dataflow, where "what is now stale?" is resolved with no human in the loop. The three mid-scale criteria all reflect the same fact — an AI-and-logic origin that tinges the framing without making the structure depend on it. Vocabulary half-travels: the term "frame problem" and its companion "frame axiom" come from McCarthy–Hayes situation-calculus AI, yet the underlying move — after a change, which facts persist by default and which need re-derivation — is recognized, not imported, when it reappears as stare-decisis-plus-distinguishing in law, as change-impact analysis in project planning, as belief revision in epistemology, and as Dennett's wagon-wheeling robot in cognitive science. Institutional origin sits at 0.5 because the computer-science provenance colors the prime without rooting it in a human institution. Import-versus-recognize is likewise 0.5: invoking it mostly recognizes a relevance-closure problem already present in any incrementally-updated representation, with only a light technical overlay from non-monotonic logic. The honest reading, matching the 0.3 grade, is a substrate-neutral closure-under-update structure lightly colored by its AI home vocabulary — structural, with a modest framed tinge.

Substrate Independence¶

The frame problem is a strongly substrate-independent prime — composite 4 / 5 on the substrate-independence scale, a relevance-closure pattern recognized across domains rather than translated into them. Its domain breadth is high (4 / 5): the bounding-ramifications-after-an-update structure recurs with the same force across artificial intelligence (the McCarthy–Hayes frame axioms, closed-world assumption, successor-state axioms), law (stare decisis and distinguishing as a closure mechanism over prior holdings), project planning and change management (dependency graphs and critical-chain tools bounding what a scope change invalidates), software systems (build-system DAGs, cache invalidation, reactive UIs resolving "what is now stale?"), cognitive science and philosophy of mind (Dennett's wagon-wheeling robot), scientific revision, and editorial work — reaching into fully mechanical substrates where no human is in the loop. Its structural abstraction is high (4 / 5): the signature is a substrate-neutral three-valued partition (direct effect, frame-of-persistence, relevant ramifications, plus a now-uncertain residual) governed by a closure rule, with siblings in non-monotonic logic and belief revision — none of which carry domain-specific commitment. Transfer evidence is concrete and documented (4 / 5): explicit dependency graphs, closure-by-default rules, re-derivation triggers, and frame audits are named families of moves shown traveling between build systems, legal harmonization passes, and change-control reviews, and the same too-loose/too-tight failure signature (the "works after clean rebuild" bug; paralyzing churn) is exhibited identically across substrates. The only thing keeping the composite shy of the top is the AI/logic home vocabulary — "frame problem" and "frame axiom" are situation-calculus terms — so a light technical overlay rides along, but the underlying closure-under-update question is genuinely medium-neutral.

Composite substrate independence — 4 / 5
Domain breadth — 4 / 5
Structural abstraction — 4 / 5
Transfer evidence — 4 / 5

Neighborhood in Abstraction Space¶

Frame Problem sits among the more crowded primes in the catalog (19^th percentile for distinctiveness): several abstractions describe nearly the same structure, so a description that fits it will tend to fit its neighbors too — transporting it usually means disambiguating within this family rather than landing on it exactly.

Family — Generative Rules & Stage-Wise Change (19 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-06-14

Not to Be Confused With¶

The frame problem's nearest neighbour by embedding is framing, and the confusion is almost entirely an artifact of the shared word — yet it is worth dispelling carefully because the two concern opposite things. Framing is the selection of which aspects of a situation to foreground, shaping how a receiver interprets a fixed state of affairs: the same fact-set described as "95% survival" or "5% mortality" frames the identical situation differently. Its object is a static scene and its lever is salience. The frame problem is about bounding the consequences of a change: after an event alters part of a represented world, which other facts must be re-derived and which persist by default. Its object is an update and its lever is a closure rule. The word "frame" means almost contrary things in the two — in framing it is the interpretive lens placed over a situation; in the frame problem it is (via the historical "frame axiom") the region of facts that stay put across a change. A practitioner who imports framing intuitions into a frame-problem context will look for how the change is being described or foregrounded when the actual difficulty is the transitive closure of indirect effects an undeclared dependency lets slip through. The diagnostic that separates them: framing asks "which aspects of this fixed situation are being foregrounded?"; the frame problem asks "after this change, which facts persist and which need re-derivation?"

The frame problem should also be held apart from cognitive_reframing, with which it is merged because both involve "frames" and both touch how an agent's representation handles new information. Cognitive reframing is the deliberate act of adopting a different interpretive lens on a situation — switching from "failure" to "learning opportunity," from "threat" to "challenge" — to change one's appraisal and response. Its move is between frames: discard one lens, take up another. The frame problem operates within a single frame: given one representation, maintain its coherence under incremental change by correctly bounding what must be updated. Reframing changes the representation wholesale; the frame problem keeps a fixed representation consistent as facts change inside it. The two can even run in opposite directions — reframing deliberately abandons the current closure to see the situation anew, whereas the frame problem's whole discipline is preserving a closure (most facts persist) so reasoning stays tractable. Confusing them leads a practitioner to attempt a perspective-shift when the actual task is relevance-maintenance within the current view, or to leave a stale closure rule unexamined because they mistook the need for a frame audit (re-checking persistence) for an invitation to reframe (adopt a new lens entirely).

These distinctions matter because each frame names a different operation on a different object. Framing and cognitive reframing both act on interpretation — what lens is placed on a situation — while the frame problem acts on relevance-closure under change — which facts survive an update. Reading a ramification-bounding problem as a framing or reframing problem sends effort to how the change is described or perceived, leaving the actual hard part, the unaudited cloud of indirect consequences, entirely unmanaged.

Solution Archetypes¶

No catalogued solution archetypes reference this prime yet.