How Sudoku Difficulty Is Rated

There is no universal Sudoku difficulty scale.

“Medium,” “Hard,” or “Expert” are product labels produced by a rating system.

Two Sudoku sites can legitimately place the same or similar puzzle in different categories because they may use:

• different technique libraries;
• different technique weights;
• different solver priorities;
• different thresholds;
• different player populations;
• different numbers of difficulty bands.

The useful question for VeyraPlay is therefore not:

What is the objectively correct universal label?

It is:

Can we build a rating model that is consistent, explainable, and well calibrated for our players?

Difficulty is not clue count

A tempting formula is:

fewer clues = harder

It fails quickly.

Clue count tells you how many givens the puzzle starts with.

It does not directly tell you:

• which deductions are available;
• how easy they are to notice;
• what sequence is required;
• how deeply steps depend on previous eliminations.

Two 25-clue puzzles can feel completely different.

A puzzle with more clues can still hide an Advanced dependency.

So VeyraPlay should store clue count as metadata, not treat it as the primary rating.

Difficulty starts with a human-style solve path

Before rating the puzzle, VeyraPlay needs an analyzer capable of solving it with the supported human technique set.

Example path:

Hidden Single
Hidden Single
Locked Candidates
Naked Pair
Hidden Single
X-Wing
Naked Single
...

The path lets us ask richer questions than:

How empty is the starting board?

Feature 1 — Hardest required technique

A first useful feature is:

What is the most advanced technique that the chosen human solve path actually needs?

Example concept:

Singles
→ Easy

Locked Candidates / Pairs
→ Medium

X-Wing / XY-Wing
→ Hard

Chains / selected advanced links
→ Expert

The exact boundaries belong to the model.

This feature is understandable and easy to explain to players.

But by itself, it is not enough.

Feature 2 — Total solving work

Compare:

Puzzle A

• 35 mostly easy deductions;
• 1 X-Wing.

Puzzle B

• repeated Advanced eliminations;
• several difficult candidate states;
• much longer non-trivial path.

Both can have the same hardest_technique.

They should not necessarily receive the same score.

A rating can therefore accumulate:

• technique weights;
• counts;
• step cost.

Feature 3 — Dependency structure

Research by Radek Pelánek evaluated Sudoku difficulty models against human solving data and highlighted two major sources of difficulty:

• complexity of individual solving steps;
• structure of dependencies among steps.

That second factor is important.

Imagine two X-Wings.

X-Wing A

Visible immediately after a simple placement.

X-Wing B

Only becomes available after:

• three eliminations;
• candidate cleanup;
• one Locked Candidate;
• a previous subset.

The named technique is identical.

The cognitive path to discovering it is not.

Feature 4 — Recognition burden

Some deductions are easy to verify after they are highlighted and hard to discover unaided.

Recognition can depend on:

• candidate density;
• number of distractor patterns;
• spread across the grid;
• whether the relevant digit is sparse;
• whether candidate highlighting is enabled.

This is why the same logical X-Wing can be:

• easy training;
• difficult natural play.

The rating should ultimately model the actual game interface too.

Feature 5 — Solver priority

Suppose a puzzle contains:

• a Hidden Single;
• an X-Wing.

A human-style analyzer should normally use the Hidden Single first.

If the rating engine eagerly applies the X-Wing, it can artificially inflate the difficulty.

Therefore the analyzer and rating model are linked.

Good policy:

simplest productive supported deduction first

This is not guaranteed to reproduce every human solve, but it creates a stable, explainable baseline.

Feature 6 — Number of available moves

A board with only one productive deduction can feel more constrained than a board offering several obvious alternatives.

Future models could track features such as:

• number of available simple moves;
• branching of reasonable human choices;
• time between forced breakthroughs.

These are later refinements, not requirements for the first rating model.

A sensible first rating model

The first version should be transparent.

Example architecture:

analysis:
  hardest_technique: x-wing
  total_steps: 51
  nontrivial_steps: 8
  technique_score: 310
  max_dependency_depth: 5

Then convert those features into:

difficulty:
  model: v1
  score: 420
  label: hard

Exact values are placeholders until Sudoku Core and puzzle samples exist.

The important part is storing the features and model version, not baking unexplained labels into content.

Technique scores should be configurable

A technique taxonomy will evolve.

We may discover through player data that:

• Hidden Triple deserves more weight;
• X-Wing is easier than expected with candidate highlighting;
• W-Wing creates a sharp difficulty jump;
• some chain lengths need separate scoring.

So technique weights should live in configuration/data, not be scattered through engine code.

Conceptually:

techniques:
  hidden-single:
    base_score: ...
  locked-candidates:
    base_score: ...
  x-wing:
    base_score: ...

The values can be calibrated later.

Difficulty labels are product buckets

The continuous internal score can be mapped to:

• Easy;
• Medium;
• Hard;
• Expert.

Those labels should mean something practical.

Easy

Frequent visible progress; mostly direct placements.

Medium

Candidate eliminations become normal; intersections and subsets appear.

Hard

Advanced pattern recognition is required.

Expert

Link/chain or other high-recognition logic becomes central.

The separate Sudoku Difficulty Levels Guide explains this player-facing interpretation.

This page explains the rating machinery underneath it.

Calibrate with real player data

Once VeyraPlay has enough sessions, compare model predictions against behavior.

Useful signals may include:

• completion rate;
• median solve time;
• hint usage;
• exact hint depth;
• abandon rate;
• error/undo patterns;
• candidate-mode usage;
• technique-specific stalls.

Example:

If puzzles rated Medium consistently show:

• high abandon rate;
• repeated exact-technique hints;
• solve times overlapping Expert,

the thresholds or technique weights may be wrong.

Player data should calibrate the model — not silently redefine puzzle correctness.

Segment player skill

A puzzle's intrinsic model score and a player's personal experience are related but not identical.

Later, VeyraPlay may estimate:

• global puzzle difficulty;
• personal expected difficulty.

For example:

Puzzle: Hard
For this player: Comfortable

because the player has mastered X-Wing and XY-Wing.

That is a personalization layer.

It should not overwrite the stable catalog rating.

Exercise difficulty is different

An X-Wing lesson can have several training difficulties.

Assisted

• target digit highlighted;
• base row hinted.

Guided

• family hint;
• no exact source cells.

Independent

• full candidate board;
• no pre-highlighting.

Distractor-heavy

• multiple candidate patterns;
• learner chooses search family.

Same technique.

Different recognition challenge.

So Learn should store:

technique difficulty
≠
exercise assistance difficulty
≠
full puzzle difficulty

Version difficulty models

Suppose rating-v2 improves weights.

An old published puzzle might move from:

Medium

to:

Hard

under the new calculation.

Do not lose provenance.

Store:

difficulty_label: medium
difficulty_score: 298
difficulty_model: v1

If reclassification occurs, we can decide intentionally whether catalog labels migrate.

Versioning prevents silent inconsistency.

Difficulty model QA

Before launch, rating should be tested on:

• hundreds/thousands of generated puzzles;
• known technique-path fixtures;
• edge cases;
• selected manually reviewed puzzles.

Questions:

• Are Easy puzzles actually Singles-heavy?
• Do Medium puzzles avoid unsupported Advanced steps?
• Does Hard contain enough variety?
• Are two puzzles with very similar paths rated similarly?
• Does clue count accidentally dominate?
• Are some techniques systematically overweighted?

The model needs a benchmark set, not only intuition.

FAQ

Is there an official Sudoku difficulty scale?

No universal one.

Does fewer clues mean harder?

Not reliably.

Is the hardest technique enough to rate a puzzle?

No. Total work and dependency structure matter too.

Why can another app call my Hard puzzle Medium?

Its model, thresholds, or technique taxonomy may differ.

Can player data improve difficulty ratings?

Yes. Human performance is particularly useful for calibration.

Can the same technique appear in different difficulty puzzles?

Absolutely. Context and recognition burden matter.

What to learn next

Read Sudoku Difficulty Levels for the player-facing meaning of Easy/Medium/Hard/Expert.

Read How Sudoku Puzzles Are Generated for where rating fits in the pipeline.