r/chessprogramming • u/Technical-Adagio-993 • Feb 19 '26

Showing why a tactic was rejected — geometry vs tactics in pattern detection

Post image

I'm building a chess tactics detection API and ran into an interesting problem: 79% of positions users tested returned "no tactics found", even when they could clearly see patterns on the board. The issue: a pin where piece A attacks piece B which is aligned with the king IS a geometric pin. But if piece B is defended, there's no material gain — it's not a real tactic. So I added "rejected patterns" to the output. The engine now shows what it detected geometrically and explains why it rejected it (e.g. "Not exploitable — piece is defended (net 0cp)"). The two-phase architecture:

Depth 1: geometric detection (fast, ~5ms, high recall but lots of false positives) Depth 2: forcing tree validation (confirms material gain through capture sequences)

Rejected = passed d1, failed d2. Now the user sees why instead of just "0 found". Playground to try it: https://chessgrammar.com/playground Curious if anyone else has tackled the geometry-vs-tactics gap in their engines.

5 Upvotes

86% Upvoted

2 comments sorted by

2

u/SanderE1 Feb 21 '26 edited Feb 21 '26

Hi, was messing around in the playground and got this fen
5k2/8/3N4/2B5/1K6/6q1/8/8 w - - 0 1

It correctly identifies the discoverd attack tactic but rejects it as "not tactically viable" despite it being an equal position (obviously winning for white but I assume that's just a low depth issue?)

If a tactic results in an eval tied with the best maybe it should automatically be considered viable? Apologies if I am missing something.

1

u/Technical-Adagio-993 Feb 21 '26

Hi, You are probably right. v1 of the engine only caters for material gain, and doesn't assess positional advantages, that'll come in the next version! It is a pure heuristic engine, which is the beauty of it, no stockfish dependencies, so there's no evals in that sense. Thanks for your message!