Which Model Should You Use? MR.Q, EBT, SICQL, HRM, Tiny and PACS Compared

This is the final post in Models From First Principles.

The earlier posts asked a sequence of architectural questions:

• how do we score a context-response pair?
• when is one scalar no longer enough?
• when should Q, V and policy become explicit components?
• when is one forward pass insufficient?
• when does recurrence help?
• when does hierarchy help?
• when is a smaller recursive model a better trade-off?
• when should attention or a sparse autoencoder be added?
• when should we change the optimizer rather than the model?

This post asks the question that matters when building a real system:

Which one should I actually use?

The short answer is deliberately conservative:

Use the simplest model that solves the decision you actually have.

Do not choose HRM because it sounds more sophisticated than MR.Q.

Do not choose Tiny because recursion sounds more like reasoning.

Do not choose SICQL because three heads sound more intelligent than one.

Do not choose PACS because it is a custom optimizer.

Every additional component creates another hypothesis that must earn its place.

The family we have built can be summarized like this:

MR.Q
  |
  |  one score is not enough
  v
EBT
  |
  |  the heads need to become explicit components
  v
SICQL
  |
  |  one forward pass is not enough
  v
HRM
  |
  |  hierarchy may be more machinery than we need
  v
Tiny
  |
  |  inspect the recursive model internally
  v
Residual / Attention / SAE components

Meanwhile:

model architecture
      |
      |  optimization itself becomes the bottleneck
      v
PACS

That diagram is not a leaderboard.

It is a decision path.

1. First: these models are not simply levels in a power ladder

It would be easy to read the series as:

MR.Q < EBT < SICQL < HRM < Tiny

That is the wrong interpretation.

A more complex architecture is not automatically a better architecture.

The right question is:

What does my task require?
        +
What evidence do I have that the extra machinery helps?
        +
What latency, memory, training and maintenance cost can I afford?

A well-trained MR.Q can be the correct production model even if HRM exists.

A feed-forward scorer can beat a recursive model on a task that does not benefit from iterative computation.

A single scalar can be better than a multi-head system when the deployment decision itself is scalar.

A standard optimizer can be better than PACS if it reaches the same validation quality faster and with less tuning.

So throughout this post we will separate four things:

capability requirement
architecture
training objective
evidence

The model name is not the evidence.

2. The one-page decision table

Here is the high-level selection guide.

The rest of the article explains how to make each choice.

3. Start with the decision, not the model

Before choosing architecture, write down the runtime decision your system must make.

Examples:

Score this candidate from bad to good.

Rank these ten responses for the same prompt.

Estimate candidate quality and how much better it is than the expected baseline.

Choose one of three actions after evaluating the candidate.

Spend more computation on difficult examples and less on easy examples.

Provide a quality score plus uncertainty and OOD diagnostics.

These are different problems.

The architecture should follow the problem.

A useful design rule is:

one decision variable      -> start with one head
multiple decision signals  -> consider multiple heads
iterative improvement      -> consider recurrence
multiple timescales        -> consider hierarchy
optimization instability   -> investigate optimizer changes

4. MR.Q: use it when one good scalar is enough

MR.Q is the default starting point.

Its essential architecture is:

context embedding
        +
response embedding
        |
        v
    pair encoder
        |
        v
latent representation
        |
        v
 scalar predictor
        |
        v
      Q value

The model answers one question:

How valuable is this candidate in this context, according to the target we trained on?

That target might be:

• preference;
• relevance;
• acceptance probability;
• human quality score;
• downstream reward;
• ranking utility;
• task success.

The architecture itself does not decide which.

When MR.Q is the right choice

Use MR.Q when your production decision is fundamentally scalar.

Examples:

Reranking

You have 20 generated candidates and need the best one.

scores = model(context.repeat(20, 1), candidates)
best = candidates[scores.argmax()]

You may not need V.

You may not need a policy head.

You may not need recurrent state.

You need a good ordering.

Filtering

You want to reject candidates below a threshold.

Q < threshold -> reject
Q >= threshold -> keep

Again, one calibrated scalar can be sufficient.

A cheap critic in a larger pipeline

A larger model generates candidates.

MR.Q scores them locally.

expensive generator
       |
       v
  N candidates
       |
       v
 cheap MR.Q scorer
       |
       v
 best candidate

This is often a very attractive deployment shape.

MR.Q advantages

1. Lowest conceptual complexity

There is very little machinery to misunderstand.

2. Low latency

One encoder pass and one scalar head.

3. Easy debugging

The diagnostic chain is short:

inputs
  -> representation
  -> scalar
  -> loss
  -> gradient
  -> update

4. Easy calibration

If the scalar is supposed to behave like a probability, calibration is straightforward to inspect.

5. Strong baseline

Any more complex model should beat MR.Q on the actual metric that matters before it replaces it.

MR.Q disadvantages

1. Everything is compressed into one number

You cannot naturally distinguish:

candidate value
baseline expectation
recommended action
uncertainty
OOD risk

unless you derive or bolt those on separately.

2. Limited internal diagnostics

A bad score tells you less about why the model reached it.

3. No iterative computation

It processes the pair once.

If repeated refinement genuinely helps the task, MR.Q cannot express that directly.

Upgrade from MR.Q only when…

Upgrade when you can state the missing variable clearly.

Good reason:

We need to distinguish absolute candidate value from value relative to the context baseline.

Weak reason:

EBT is more advanced.

5. EBT: use it when one representation must support several decisions

EBT keeps the shared representation but adds several heads.

context + candidate
        |
        v
   shared encoder
        |
        v
        z
   /    |     \
  v     v      v
 Q     V     Policy
 |     |       |
 +--Q-V       logits
    |
 advantage

This is the first important architectural expansion.

The representation is still computed once.

Several small models then interpret it differently.

When EBT is the right choice

Use EBT when the application genuinely benefits from several related signals.

Candidate value plus baseline

Suppose two candidates both score 0.8.

That can mean very different things depending on context.

context A baseline: 0.79
candidate score:    0.80
advantage:           0.01

versus:

context B baseline: 0.30
candidate score:    0.80
advantage:           0.50

A single Q score does not expose that distinction.

A Q/V decomposition can.

Scoring plus action recommendation

Your runtime might need to decide:

ACCEPT
REVISE
REJECT

You can force those decisions from thresholds on Q.

But a policy head allows the model to learn a separate action surface.

That can be useful when the optimal action is not a monotonic function of score.

Multi-task supervision

You may have several labels per example:

quality score
action label
baseline expectation

A shared representation can learn from all of them.

EBT advantages

1. Extra outputs are relatively cheap

The expensive representation is shared.

Heads are small.

2. Richer runtime information

Instead of:

Q = 0.73

you can have:

Q = 0.73
V = 0.51
A = 0.22
policy = [0.76, 0.19, 0.05]

3. Multi-task regularization can help

Different objectives can force the representation to retain useful structure.

But this is an empirical possibility, not a guarantee.

4. Natural bridge to decision modelling

You begin separating evaluation from action.

EBT disadvantages

1. Multi-task interference

The Q objective may want to move the shared representation one way.

The policy objective may want to move it another.

The V objective may pull in a third direction.

You should inspect gradient conflict rather than assuming the heads cooperate.

2. Loss weighting becomes a real design problem

loss = q_loss + 0.2 * v_loss + 0.1 * policy_loss

Why 0.2?

Why 0.1?

Those weights can materially change the representation.

3. Head names can overclaim semantics

If V sees the candidate as part of the shared representation, calling it a pure V(s) may be mathematically misleading.

4. More outputs create more calibration problems

Each head can be wrong in a different way.

Prefer EBT over MR.Q when…

The extra signals improve decisions enough to justify their training and maintenance cost.

Not merely because they exist.

6. SICQL: use it when the heads need to become real components

EBT and SICQL can look similar from far away.

Both can expose:

Q
V
Policy
Advantage

The major practical difference is architectural explicitness.

SICQL makes the components first-class modules.

PairEncoder
QHead
VHead
PolicyHead
InContextQModel

That changes what you can do experimentally and operationally.

When SICQL is the right choice

Use SICQL when you need to manipulate these parts independently.

Independent head training

Perhaps your Q labels are plentiful but policy labels are scarce.

You can train:

encoder + QHead

first.

Then freeze them and train:

PolicyHead

later.

Independent checkpointing

You may want:

encoder_v7.pt
q_head_v12.pt
v_head_v4.pt
policy_head_v9.pt

That is much easier when the architecture recognizes those as real boundaries.

Head replacement

You can test:

small Q head
vs
large Q head

without rewriting the rest of the system.

Different value semantics

You can replace a candidate-conditioned V with a true context-only V while leaving Q and Policy untouched.

That is a powerful experimental capability.

SICQL advantages

1. Maximum modularity among the one-pass family

Every major semantic surface is explicit.

2. Better ablation discipline

You can remove or replace one component cleanly.

3. Better checkpoint discipline

Model compatibility becomes easier to reason about.

4. Better parameter ownership

Optimizers can target selected modules explicitly.

optimizer = torch.optim.AdamW(
    model.q_head.parameters(),
    lr=1e-4,
)

5. Easier transfer and probing

A head can be frozen, replaced or probed independently.

SICQL disadvantages

1. Software complexity

Every explicit component creates an interface.

Interfaces can drift.

2. Representation compatibility matters

A Q head trained against encoder version 3 may not behave correctly with encoder version 5.

3. More checkpoint combinations

Modularity gives freedom.

Freedom creates configuration space.

4. The architecture can become over-engineered

If you always train and deploy the entire model as one inseparable artifact, SICQL’s modularity may buy little over a simpler EBT-style implementation.

Prefer SICQL over EBT when…

You can name an operation you want to perform independently:

replace
freeze
ablate
checkpoint
transfer
probe
retrain

If you cannot, EBT may remain the cleaner choice.

7. HRM: use it when one forward pass has become the limitation

Everything so far is mostly feed-forward.

The model sees its inputs and produces outputs.

HRM changes the computation itself.

input
  |
  v
projection
  |
  v
 x_tilde
  |
  +------------------+
  |                  |
  v                  |
low-level state      |
 zL -> zL -> zL      |
  |                  |
  v                  |
high-level state     |
 zH -------> zH -----+

The low-level state updates several times.

The high-level state updates less frequently.

The parameters are reused across those steps.

This creates more computation without requiring a completely new set of weights at every step.

When HRM is the right choice

Use HRM only when you have evidence that iterative, multi-timescale computation matters.

Difficult examples benefit from repeated computation

Suppose validation accuracy changes with recurrence depth:

1 cycle  -> 72.1%
2 cycles -> 75.8%
4 cycles -> 79.4%

and the gain survives compute-matched baselines.

Now recurrence has evidence behind it.

Fast and slow latent features emerge

You may find that probes trained on zL and zH behave differently.

For example:

zL predicts local formatting defects well
zH predicts overall acceptance well

That would be evidence that the hierarchy has learned specialization.

Adaptive computation becomes valuable

Some examples may settle quickly.

Others may need more cycles.

If trajectory diagnostics show this reliably, an HRM-style architecture can support a more adaptive runtime.

HRM advantages

1. More computation per parameter

The same recurrent blocks are reused.

2. Two explicit timescales

The architecture can, in principle, learn different roles for low- and high-level state.

3. Rich trajectory information

You can inspect:

zL at each step
zH at each cycle
score by cycle
state delta
convergence

4. Strong fit for tasks where refinement matters

If the task genuinely benefits from repeated latent processing, HRM gives the model a mechanism for it.

HRM disadvantages

1. Highest inference cost in this family

Parameter count can be modest while runtime compute is large.

Do not confuse those two quantities.

2. More difficult optimization

Gradients pass through repeated recurrent applications.

3. More difficult debugging

A failure can originate from:

input projection
low-level recurrence
high-level recurrence
normalization
cycle scheduling
head behavior
loss weighting

4. Hierarchy may not actually specialize

Two states with two update frequencies do not prove hierarchical reasoning.

5. Latency can become unacceptable

A model that is 2% better but 8× slower may be the wrong production model.

Prefer HRM over SICQL when…

Your controlled tests show that additional recurrent computation itself creates useful gains, and that the hierarchical schedule beats a simpler recurrent control.

That second clause matters.

Because otherwise you may want Tiny.

8. Tiny: use it when recurrence helps but hierarchy does not earn its cost

Tiny asks a very useful control question:

Do we need two recurrent states, or do we mostly need repeated latent refinement?

Its core is simpler:

context
candidate
latent z
   |
   v
concatenate
   |
   v
projection
   |
   v
core block
   |
   v
update
   |
   v
z <- z + alpha * update
   |
 repeat

One state.

One update rule.

Repeated computation.

When Tiny is the right choice

Recurrence beats feed-forward, but HRM does not beat Tiny

This is perhaps the clearest use case.

Suppose:

MR.Q / feed-forward: 74.0
Tiny:                 80.1
HRM:                  80.3

If HRM is materially slower and more complex, Tiny wins.

You need an explicit computation knob

Tiny makes recursion depth easy to control.

model(x, y, n_steps=2)
model(x, y, n_steps=4)
model(x, y, n_steps=8)

That makes it attractive for adaptive-compute experiments.

You want a compact critic or evaluator

The recursive core can stay relatively small while reusing its weights multiple times.

You want to study latent refinement itself

Tiny is easier to analyze than a two-level recurrent hierarchy.

Tiny advantages

1. Simple recurrent mechanism

The recurrence is easy to draw and easy to inspect.

2. Good parameter efficiency

Repeated compute comes from reused weights.

3. Natural computation-depth control

This is valuable both scientifically and operationally.

4. Strong control model for HRM

It lets you ask:

recurrence?

versus:

hierarchical recurrence?

5. Easy internal experimentation

The core can be swapped:

MLP
attention
other residual block

The bottleneck can be swapped:

none
dense AE
sparse AE

Tiny disadvantages

1. A single latent state may collapse useful structure

If low-level and high-level state genuinely specialize in HRM, Tiny cannot represent that separation explicitly.

2. Recurrence still costs time

A 2-million-parameter model executed eight times is not a one-pass 2-million-parameter model operationally.

3. Step scale becomes important

z <- z + alpha * update

A poor alpha can make updates too weak or unstable.

4. Halting is another learned claim

A halt_head is not automatically a trustworthy compute controller.

5. Extra internals can become decorative

Attention and sparse autoencoders should remain only if ablation says they help the relevant objective.

Prefer Tiny over HRM when…

Recurrence helps, but the second timescale does not provide enough measurable benefit to justify its cost.

That is a very strong reason to prefer the simpler architecture.

9. What about the attention and SAE components inside Tiny?

These are not separate top-level choices in the same sense as MR.Q or HRM.

They are component choices.

But they deserve explicit decision rules.

Use an MLP core when

Your latent is a single vector and there is no meaningful sequence or set structure to route across.

[B, D]

For many embedding-based scorers, an MLP is enough.

Use attention when

There are meaningful positions or slots.

For example:

[context, candidate, latent]

or a real token/segment sequence:

[B, T, D]

Then attention can route information among distinct elements.

Do not add attention merely because it is available

Self-attention over a sequence length of one has no meaningful routing choice.

Compare:

MLP
vs
one-position attention
vs
slot attention

and measure the task outcome.

Use a sparse autoencoder when

You have a concrete reason to impose or study a sparse latent code.

Examples:

• interpretability experiments;
• feature interventions;
• latent dictionary learning;
• compact concept probes;
• decomposition of model behavior.

Do not use an SAE merely because you want to call features “concepts”

A sparse coordinate is not automatically semantically meaningful.

Look for:

sparsity
stability
non-redundancy
predictive usefulness
causal intervention effects
replication across seeds

If those do not appear, the SAE may simply be extra reconstruction machinery.

10. PACS: use it when the model is not the problem

PACS belongs on a different axis.

MR.Q, EBT, SICQL, HRM and Tiny primarily change what is computed.

PACS changes how parameters are updated.

The core update is conceptually:

gradient
   |
   +------------+
   |            |
   v            v
EMA(g)       EMA(g^2)
   |            |
   |            v
   |       preconditioner
   |            |
   +-------> divide
              |
              v
           update
              |
              v
          parameter

When PACS is the right choice

Use PACS only after you have reason to believe optimization dynamics are limiting you.

Training is noisy or unstable

Gradient averaging may help stabilize the update direction.

Parameter scales differ dramatically

Second-moment preconditioning can normalize updates coordinate-by-coordinate.

You want to study optimizer behavior directly

Because PACS is small and explicit, it is easy to instrument.

You can inspect:

raw gradient norm
first moment norm
second moment
preconditioned update norm
effective learning rate
parameter movement

Standard optimizers fail a controlled comparison

If PACS consistently beats tuned AdamW/SGD/RMSprop on the metric that matters, that is evidence.

PACS advantages

1. Mechanically simple

The update can be understood line by line.

2. Inspectable optimizer state

No need to treat optimizer.step() as magic.

3. Separate smoothing and preconditioning timescales

The first and second moments can adapt at different rates.

4. Easy to modify experimentally

You can remove smoothing, remove preconditioning or change weight-decay semantics independently.

PACS disadvantages

1. Familiar mechanisms are not automatically superior mechanisms

Gradient EMA and squared-gradient EMA already exist in established optimizer families.

The burden is on PACS to beat good baselines.

2. More hyperparameters

lr
beta
preconditioner_decay
eps
weight_decay

3. Extra optimizer state

Two tensors per parameter are not free.

4. No automatic bias correction in the implementation we examined

Early updates can therefore behave differently from Adam-style bias-corrected moments.

5. Coupled weight decay has different semantics from AdamW

Do not compare the same numeric weight_decay and assume equivalence.

PACS is not “after Tiny”

This is important.

You can have:

MR.Q + PACS
EBT + PACS
SICQL + PACS
HRM + PACS
Tiny + PACS

or none of them.

The optimizer axis is orthogonal to the architecture axis.

11. The real architecture matrix

A better way to view the family is with several axes.

PACS can be placed under any column because it affects optimization rather than forward architecture.

12. The practical selection algorithm

If I were implementing a new system, I would use this sequence.

Step 1: Can a simple baseline solve it?

Start with something embarrassingly simple.

cosine similarity
linear classifier
small MLP

If that solves the task, stop.

Do not add architecture for aesthetic reasons.

Step 2: Do I need a learned context-conditioned scalar?

If yes:

MR.Q

Step 3: Do I need several distinct learned signals from the same representation?

If yes:

EBT

Step 4: Do those signals need independent lifecycle control?

Do you need to independently:

freeze
replace
checkpoint
probe
train
ablate

If yes:

SICQL

Step 5: Does one-pass computation fail in a way that recurrence fixes?

Run the experiment.

feed-forward
vs
single-state recurrent

If recurrence does not help, stop.

If it does:

Tiny becomes a candidate

Step 6: Does hierarchical recurrence beat simple recurrence?

Compare:

Tiny
vs
HRM

under parameter-matched and compute-aware conditions.

If HRM wins materially:

HRM

If not:

Tiny

Step 7: Is optimization the remaining bottleneck?

Only now consider a custom optimizer.

Compare:

SGD
AdamW
RMSprop
PACS

with tuned learning rates and repeated seeds.

13. The decision tree

Here is the entire selection process as one tree.

Do you need a learned scorer?
 |
 +-- no --> use a deterministic/simple baseline
 |
 +-- yes
      |
      v
Is one scalar enough for the runtime decision?
 |
 +-- yes --> MR.Q
 |
 +-- no
      |
      v
Do you need Q/V/Policy-style multiple outputs?
 |
 +-- yes --> EBT
 |             |
 |             v
 |        Need independent head lifecycle?
 |             |
 |             +-- yes --> SICQL
 |             |
 |             +-- no  --> stay with EBT
 |
 +-- maybe other heads --> use the same shared-head principle

Then separately:

Does repeated computation improve the task?
 |
 +-- no --> stay feed-forward
 |
 +-- yes
      |
      v
Does a single recurrent state capture the gain?
 |
 +-- yes --> Tiny
 |
 +-- no
      |
      v
Does two-timescale hierarchy beat Tiny enough to pay for it?
 |
 +-- yes --> HRM
 |
 +-- no  --> Tiny

Finally:

Is the architecture adequate but optimization still limiting?
 |
 +-- no --> use the standard optimizer that works best
 |
 +-- yes --> benchmark PACS against tuned standard optimizers

14. What I would choose for common scenarios

Scenario A: rerank 32 LLM responses

Requirement:

prompt + candidate -> quality score

Choice:

MR.Q.

Why:

• simple;
• fast;
• batchable;
• ranking metric matches runtime use;
• easy to cache prompt embeddings;
• easy to benchmark against cosine similarity.

Do not start with HRM unless evidence says repeated computation materially improves ranking.

Scenario B: score, estimate baseline, and choose ACCEPT/REVISE/REJECT

Requirement:

quality
baseline expectation
relative advantage
action

Choice:

EBT initially.

Why:

One representation can support all four outputs cheaply.

Move to SICQL only if the heads need independent training or deployment lifecycle.

Scenario C: Q is stable, policy changes frequently

Requirement:

Q scoring is mature.

Policy rules or labels evolve often.

Choice:

SICQL.

Why:

Freeze the encoder and Q head.

Retrain or replace the policy head independently.

That is exactly where explicit component boundaries become valuable.

Scenario D: difficult cases improve when the model gets more internal steps

Requirement:

Easy cases work in one pass.

Hard cases improve with more compute.

Choice:

Start with Tiny.

Why:

It is the cleaner test of whether recurrence itself is useful.

Only move to HRM if two-timescale recurrence beats Tiny in controlled comparisons.

Scenario E: the task genuinely contains fast local and slow global structure

Suppose experiments show:

zL -> local defect detection
zH -> overall quality / long-range decision

and HRM beats Tiny at acceptable latency.

Choice:

HRM.

Now the hierarchy has empirical justification.

Scenario F: Tiny works, but training is highly noisy

Architecture is already good.

Validation quality is sensitive to gradient noise and parameter scale.

Choice:

Keep Tiny and benchmark PACS.

Do not rewrite the architecture to solve an optimization problem.

Scenario G: production has a 2 ms budget

Choice:

Probably MR.Q, possibly a very small EBT/SICQL.

HRM and deep Tiny recursion should have to demonstrate extraordinary value to justify violating the latency budget.

Architecture is constrained by the system it lives inside.

Scenario H: offline evaluator with no strict latency budget

Choice:

Tiny or HRM become more plausible.

If evaluations happen offline, repeated computation may be cheap relative to the value of better ranking or diagnostics.

Runtime economics change the architecture decision.

15. Advantages are only advantages relative to the task

This deserves emphasis.

Consider recurrence.

For one task:

more compute -> better decisions

Recurrence is an advantage.

For another:

more compute -> same decisions

Recurrence is pure cost.

Consider multiple heads.

For one dataset:

policy supervision improves shared features

Multi-task learning is an advantage.

For another:

policy gradients fight Q gradients

It is a disadvantage.

Consider an SAE.

For one research objective:

stable sparse features enable interventions

The SAE is valuable.

For a pure ranking deployment:

same ranking accuracy + more parameters + more maintenance

It may be pointless.

There are almost no architecture features that are universally good.

16. Compare models on the metric the system actually uses

Do not compare models using a metric merely because it is easy to compute.

If production chooses the best candidate among ten responses, evaluate ranking.

Useful metrics include:

pairwise accuracy
MRR
NDCG
precision@1
regret of selected candidate

If production thresholds a calibrated probability, evaluate calibration.

Brier score
ECE
reliability curves
precision/recall at operational threshold

If production uses uncertainty to route expensive review, evaluate the routing policy itself.

For example:

fraction escalated
error rate among non-escalated cases
cost per accepted decision

The best architecture is the one that improves the actual system objective.

17. Compare cost on more than parameter count

A common mistake is to report:

Tiny has X parameters.
HRM has Y parameters.

and stop.

That misses repeated computation.

Track at least:

parameter count
optimizer-state memory
activation memory
forward FLOPs
backward FLOPs
latency
throughput
energy or accelerator time if relevant

A recurrent model can be parameter-efficient and compute-expensive at the same time.

Those are not contradictions.

18. The model should earn every upgrade

The cleanest development strategy is progressive escalation.

baseline
  |
  v
MR.Q
  |
  | evidence for extra signals
  v
EBT
  |
  | evidence for modular lifecycle
  v
SICQL
  |
  | evidence for recurrence
  v
Tiny
  |
  | evidence for hierarchy
  v
HRM

At each arrow, ask:

What failure of the current model are we fixing?
What new mechanism fixes it?
What metric should improve if the hypothesis is true?
What simpler control could explain the same gain?
What new cost are we accepting?

If you cannot answer those questions, do not upgrade yet.

19. Keep the old model as a control

When moving from MR.Q to EBT, do not delete MR.Q.

When moving from Tiny to HRM, do not delete Tiny.

Keep them runnable.

The earlier model becomes your control.

That gives you a living experimental ladder:

MR.Q
EBT
SICQL
Tiny
HRM

Run them against the same benchmark.

Track:

quality
latency
memory
training stability
calibration
seed variance
operational cost

Then the architecture lineage becomes measurable rather than historical.

20. A model registry should store evidence, not only names

If these architectures live in a real platform, the registry should not merely contain:

{
    "mrq": MRQModel,
    "ebt": EBTModel,
    "sicql": SICQLModel,
    "hrm": HRMModel,
    "tiny": TinyModel,
}

It should also contain evidence and constraints.

Conceptually:

ModelCard(
    name="tiny",
    task="pair_ranking",
    embedding_version="v7",
    validation_ndcg=0.842,
    latency_ms=3.7,
    peak_memory_mb=81,
    seed_std=0.006,
    benchmark_version="2026-08-08",
)

Then model selection can become an engineering decision.

Not folklore.

21. The system can route between models

The choice does not always have to be global.

A production system can use models hierarchically.

For example:

100 candidates
     |
     v
cheap MR.Q
     |
     v
 top 10
     |
     v
Tiny
     |
     v
 top 3
     |
     v
HRM
     |
     v
 final selection

This can produce a better cost-quality frontier than running HRM over every candidate.

Another pattern:

MR.Q confidence high
        |
        +-- yes --> accept result
        |
        +-- no --> Tiny / HRM escalation

Now the architectures become specialists at different compute tiers.

That can be more useful than declaring one universal winner.

22. But routing also has to earn its complexity

A cascade introduces new failure modes:

cheap model filters out the true best candidate
confidence router is miscalibrated
later model never sees difficult examples
latency becomes unpredictable
multiple checkpoints drift

So compare:

single strong model

against:

cascade of cheap + expensive models

at the same total cost.

Again: architecture is a hypothesis.

23. A concise pros-and-cons summary

MR.Q

Advantages

• smallest conceptual surface;
• low latency;
• easy ranking/calibration;
• easy debugging;
• strong production baseline;
• ideal for reranking and filtering.

Disadvantages

• one scalar hides structure;
• limited diagnostics;
• no explicit baseline/action decomposition;
• no recurrent computation.

EBT

Advantages

• multiple useful signals from one representation;
• cheap heads;
• natural Q/V/Policy decomposition;
• advantage becomes explicit;
• good multi-task learning test bed.

Disadvantages

• gradient conflict;
• loss-weight tuning;
• more calibration surfaces;
• head semantics can be ambiguous.

SICQL

Advantages

• strongest modularity in the one-pass family;
• independent heads;
• clean ablations;
• partial checkpoints;
• component replacement;
• clearer parameter ownership.

Disadvantages

• interface complexity;
• checkpoint compatibility burden;
• more configuration combinations;
• can be unnecessary if components never vary independently.

HRM

Advantages

• iterative computation;
• parameter reuse;
• multiple recurrent timescales;
• rich trajectories;
• potential adaptive compute;
• potential low/high state specialization.

Disadvantages

• highest runtime complexity;
• harder optimization;
• harder debugging;
• specialization is not guaranteed;
• latency can dominate any quality gain.

Tiny

Advantages

• simpler recurrence;
• strong parameter efficiency;
• easy depth control;
• excellent HRM control model;
• swappable core;
• easy trajectory analysis.

Disadvantages

• one state may lose hierarchy;
• repeated compute still costs runtime;
• step-scale sensitivity;
• halting requires validation;
• optional internals can become decorative complexity.

PACS

Advantages

• transparent custom optimization;
• gradient smoothing;
• coordinate-wise preconditioning;
• easy instrumentation;
• useful optimizer ablation platform.

Disadvantages

• more tuning;
• extra optimizer state;
• familiar mechanisms may not beat standard optimizers;
• weight-decay semantics matter;
• no automatic guarantee of better convergence.

24. My default choices

If I had no benchmark results yet, my priors would be:

Need one score?

MR.Q.

Need several related outputs?

EBT.

Need those outputs independently manageable?

SICQL.

Need recurrence?

Tiny first.

Have evidence that two recurrent timescales matter?

HRM.

Have evidence the architecture is fine but optimizer dynamics are limiting?

Benchmark PACS.

That ordering deliberately gives simplicity the benefit of the doubt.

The complex model has to win the argument.

25. The most important comparison is not model versus model

The most important comparison is:

complexity added
        versus
measurable value created

Suppose HRM improves NDCG from:

0.841 -> 0.844

but multiplies latency by five.

That may be a loss.

Suppose EBT improves ranking only slightly but its policy head eliminates a costly downstream model call 30% of the time.

That may be a major win.

Suppose Tiny gives the same accuracy as HRM but exposes a cleaner adaptive-compute mechanism.

Tiny may be preferable even at equal accuracy.

The deployment objective is larger than the model metric.

26. The whole series in one idea

We began the series with a claim:

A sophisticated model becomes understandable when you recursively decompose it.

We can now go the other direction.

Start from basic operations:

matrix multiply
normalization
activation
addition
moving average

Compose them into components:

encoder
head
residual block
recurrent block
autoencoder
optimizer

Compose those into models:

MR.Q
EBT
SICQL
HRM
Tiny

Then compose models into systems:

generate
score
rank
route
refine
select

At no point do we need magic.

What changes is the arrangement of ordinary mechanisms.

27. Final rule: choose by evidence, not architectural prestige

There is a temptation in machine learning to move toward the most sophisticated architecture available.

That reverses the engineering process.

The better process is:

start simple
measure failure
identify missing capability
add the smallest mechanism that could fix it
measure again
keep it only if it earns its cost

So:

Use MR.Q when one score solves the problem.

Use EBT when several related signals genuinely improve the decision.

Use SICQL when those signals need independent architectural lives.

Use Tiny when repeated latent refinement helps and a single recursive state is enough.

Use HRM when hierarchy itself demonstrates value beyond simple recurrence.

Use PACS when the remaining problem is parameter-update dynamics rather than model structure.

And if a linear model solves the task better at the required latency and cost?

Use the linear model.

That is not a failure to use the advanced architecture.

That is the point of understanding the architecture in the first place.

Series complete

Models From First Principles has moved from the smallest pair scorer through multi-head decision models, modular Q/V/Policy components, hierarchical recurrence, compact recursive reasoning, residual/attention/SAE internals, and finally optimizer construction.

The goal was never to memorize model names.

The goal was to be able to open an unfamiliar architecture, reduce it to understandable parts, ask what each part contributes, and decide whether it deserves to exist.

Once you can do that, a model stops being a black box.

It becomes an engineering system.