Use with AI · Chapter Application

Choose the Simplest Model Architecture That Fits This Repository

Use the final Models From First Principles comparison to determine what learned components the project actually needs and which complexity is unjustified.

Chapter Application Models From First Principles Learned model architecture Intermediate → 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
You are reviewing a machine-learning repository to decide whether its current model architecture matches the decision problem it actually has.

Do not rank architectures by sophistication.
Do not assume that adding value heads, policies, hierarchy, recurrence, recursive refinement or multiple learned components is an improvement.

First reconstruct the actual decision being learned.

1. Identify the model's contract.
   - What inputs does it receive?
   - What output does downstream software consume?
   - Is it estimating a scalar score, comparing alternatives, predicting value, selecting an action, maintaining state, refining an internal representation, or combining several of these?

2. Identify every learned component.
   For each component report:
   - inputs
   - outputs
   - training target / supervision source
   - loss
   - where its output affects the final decision

3. Reconstruct the information flow.
   Draw a concise dependency graph from input → learned components → decision/output.
   Separate learned computation from deterministic software.

4. Identify the minimum sufficient model class.
   Ask in order:
   - Would one scalar scorer solve the real decision?
   - Does the system genuinely need separate value/Q/policy semantics?
   - Is temporal/recurrent state required by the data or only present architecturally?
   - Does hierarchy correspond to measurable structure in the problem?
   - Does recursive/refinement computation improve a measurable outcome?
   - Are multiple learned heads providing distinct information or duplicating each other?

5. Test every additional mechanism against evidence.
   For each architectural component beyond the minimum, identify:
   - the failure it is intended to fix
   - evidence that the failure exists
   - benchmark or ablation showing the component helps
   - training/inference/maintenance cost it adds

6. Look for removable complexity.
   Flag components that:
   - have no independent target or clear semantic role
   - are never meaningfully consumed downstream
   - duplicate deterministic logic
   - cannot be validated independently
   - add state without evidence state is required
   - survive only because the architecture was copied from another system

7. Look for missing capability only after simplification.
   If the current architecture cannot represent the real decision, describe the smallest additional learned mechanism that would address the demonstrated gap.

Return:

A. Actual decision problem
B. Current learned-component graph
C. Minimum sufficient architecture
D. Components that earn their complexity
E. Components that should be ablated or removed
F. Missing evidence before changing architecture
G. One benchmark/ablation plan that can decide the question

The governing rule is:
Use the simplest model that solves the decision you actually have.