Use with AI · Chapter Application

Audit Fast and Slow Learned State

Apply Models From First Principles Step 04 to test whether hierarchical recurrent state is actually necessary and whether its fast/slow timescales remain semantically coherent.

Chapter Application Models From First Principles Hierarchical and recurrent reasoning models Advanced
Read the source chapter → View the learning path →

How to use this

  1. Open a repository-aware AI assistant.
  2. Give it access to the repository or files you want reviewed.
  3. Copy the prompt below and run it unchanged first.
  4. Use the evidence it finds to decide what to inspect or change next.
PromptCopy and run against your own project
Review this repository for hierarchical or recurrent learned state, especially architectures with fast/slow state, low/high-level state, recurrent refinement, or repeated latent updates.

Do not assume recurrence or hierarchy creates reasoning. Reconstruct what information each state is expected to retain and why one-pass computation is insufficient.

For each recurrent state identify:
- initialization;
- update equation/module;
- update frequency;
- inputs available at each update;
- reset boundary;
- detach/truncation behavior;
- persistence across examples or sequences;
- downstream consumers.

Build a state-timescale table and test:
- fast and slow states carrying the same information;
- one state dominating while the other is ignored;
- stale state crossing sequence/example boundaries;
- hidden leakage from future information;
- unstable or vanishing recurrent updates;
- iteration count chosen without evidence;
- repeated computation that converges immediately or never converges;
- hierarchy whose benefit disappears under an equal-budget feed-forward baseline.

Use exact file/symbol evidence. Distinguish measured behavior from architectural intent.

Output:
1. Recurrent state map
2. Fast/slow semantic contract
3. Reset and persistence analysis
4. Failure risks with evidence
5. Simpler equal-budget baseline
6. Ablations: remove hierarchy / reduce iterations / share state / one-pass
7. Verification metrics
8. Recommendation: Keep / Simplify / Remove hierarchy

Hierarchy earns its place only if distinct timescales produce measurable behavior a simpler model cannot match under comparable budget.