frame-problem

The Frame Problem

You cannot act or reason without assuming a frame — things you take to stay the same. The frame problem has no general solution (Fodor, 1987). This skill forces you to make frame assumptions explicit, which makes them auditable. An implicit frame can't be checked. An explicit one can. Sources: Fodor (1987), Dennett (1984), Hayes (1973).

Proportionality

Not every action needs a frame audit. If the information is fresh, the scope is narrow, and you can name your key assumption in one sentence — do that and proceed. The discipline is noticing you have a frame (Fodor), not exhaustively cataloguing it. Scale the checking to the cost of the assumption being wrong.

Four Actions

Apply in order when you suspect your frame may be wrong:

Action	Question	What to do
Name the Frame	What am I assuming stays the same?	State it. "I'm assuming the codebase is the same as when I last read it." "I'm assuming the user's goal is X." If you can't name the assumption, you can't check it.
Check Freshness	When was this information gathered, and what has happened since?	Check mtimes (ls -l) on files you're about to modify — if newer than your last read, re-read them. Turns passed since last read? User mentioned doing something? Your own prior actions had side effects? CI or deployments may have run?
Check Scope	Am I solving the right problem?	The frame includes the problem definition itself. If the user says "it's a caching issue," that's a frame. The most consequential assumption is often which problem you're solving, not how.
Name the Blind Spots	What kind of change would my current vocabulary not let me notice?	Your ontology determines what changes are visible to you. This is the hardest action — an admission of bounded rationality, stated out loud.
Rate Confidence	What part of this frame am I least confident about?	Name it. That's where to direct verification effort — and where to warn the human that your reasoning is weakest.

Fast exit: If you can name your key assumptions, verify they're current (file mtimes, recent user messages, no intervening actions), and the scope matches the user's actual request — state that in one sentence and proceed. The value was in checking, not in the ceremony of reporting. Don't write a frame audit when a frame glance suffices.

Failure Modes (Dennett's Three Robots)

Mode	Pattern	Correction
R1 — ignoring side effects	Acts without considering what else the action touches	Back up. Name the frame. What are you assuming stays the same?
R1D1 — considering everything	Traces every possible implication, never acts	You're past diminishing returns. State the cost of further checking vs. the risk of being wrong. Act.
R2D1 — meta-paralysis	Tries to enumerate what's relevant, which is itself unbounded	The relevance question has no general answer. Check what your model makes salient. Accept residual risk.

Each robot fails by trying to solve the frame problem rather than manage it.

Termination

This skill has no clean stopping rule. Fodor: "The frame problem is just Hamlet's problem viewed from an engineer's perspective." You stop checking when the expected cost of further checking exceeds the expected cost of being wrong. Say that tradeoff out loud — don't just silently stop.

Self-Checks

When you notice...	Do this
"I just read that file"	Check: how many turns ago? What has the user done since? Re-read if >2 turns.
"That's not relevant"	Pause: you chose what counts as relevant. Name the choice and check it.
"I already checked"	Ask: checked under which frame? Has anything changed since?
"The user said it's X"	Treat as hypothesis, not diagnosis. The user's frame is a frame too.
"Let me be thorough and check everything"	Stop — that's R1D1. Name the 2-3 things that matter most and why.
"This is too simple to have side effects"	That's R1. Check: simplicity of your model ≠ simplicity of the system.
"I'll verify after"	Verify now. Post-hoc verification confirms your frame; it doesn't test it.
Reasoning from information gathered many turns ago	Re-read the files before continuing.
Accepting the user's diagnosis without examining it	Name what the user is assuming. Check whether that assumption holds.
Confidence that a prior action worked	Verify it worked. Don't assume.
"Nothing else changed"	Name what you're assuming didn't change. Check the most likely one.
A second fix for something that "should have worked"	Your frame may be wrong, not your fix. Return to Name the Frame.

Examples

• Stale cache assumption — team debugs cache when the real problem is corrupted migration data
• Inherited problem framing — ticket requests rate limiting for a problem that async processing already solved

Arriving From Another Skill

• From representing-and-intervening: R&I's Update phase revealed a structural model revision — the model was wrong. Carry the old model's assumptions into Name the Frame. The question is: what did the old model assume that turned out to be false, and what other assumptions share that same basis?
• From causal-analysis: A causal claim didn't hold up. The frame to audit is the causal assumption itself — what were you assuming about the causal structure, and where did that assumption come from?

Transition Signals

• Can't name the frame because you don't have a model → suggest representing-and-intervening to the user. They need R&I's Represent phase before naming what's held constant.
• Frame check reveals the problem definition itself is wrong → suggest returning to representing-and-intervening (Problem Setting / Schon). The frame error is upstream of any solution.
• Frame check reveals a regulation mismatch → suggest requisite-variety to the user. The frame was "this regulator is sufficient" and it isn't.
• Need to establish whether a causal assumption in the frame actually holds → suggest causal-analysis to the user. The frame contains a causal claim that hasn't been tested.
• Frame is solid, assumptions verified, ready to act → if writing-plans is available, suggest it to the user.
• Frame audit revealed an untested assumption — if what-to-test is available, suggest it to the user. The assumption is what they're guarding against.

The frame problem is meta-epistemic: what am I assuming without examining, and is that assumption still valid?