Bridge Sense

TECHNICAL NOTES

How we decide what's correct.

Any coaching tool can tell you that you were wrong. The question worth asking is how it knows. This page describes the machinery, the tests it has to pass, and: at the bottom, the things it still gets wrong.

THE POINT

Why publish this at all

Bridge coaching software asks you to trust it. You make a call, something tells you it was wrong, and you adjust your game accordingly. That is a lot of trust to extend to a black box: particularly one built on a language model, which will explain a wrong answer just as fluently as a right one.

So the machinery is written down here, along with the numbers it currently produces and the places it falls short. If something on this page turns out to be wrong, we would rather you could tell.

THE APPROACH

A rule engine, not a chatbot

Not a chatbotThe correct call on every hand is decided by encoded bidding rules, not by asking a language model what it thinks. The same hand and auction always produce the same answer, and that answer can be traced to the specific rule that produced it.
Why it mattersA language model asked "what's the right bid?" will answer confidently either way. It has no mechanism for being consistently right, and no way to show you why. A rule engine can be wrong, but it is wrong in a specific, findable, fixable place.
Situations, not sequencesAuctions are classified into positions, responding to an opening, advancing a takeout double, answering a keycard ask, rather than stored as a tree of bid sequences. Interference is a parameter of the position, not a separate branch, which is what stops competitive bidding exploding combinatorially.

STRUCTURE

The four layers

1 · Hand evaluationPure functions over 13 cards: high card points, shape, suit quality, stoppers, support points, controls, keycards, losing trick count. No auction context, no state.
2 · KnowledgeWhat each seat has *shown*, built by intersecting the constraints of every call they've made. This is how the engine knows partner holds 12-14 balanced without being told.
3 · SituationClassifies the auction into one of 16 position types. This layer is why a negative, responsive, support and penalty double are four different things rather than one bid with four meanings.
4 · RulesPer-situation tables, evaluated in priority order, first match wins. Each rule declares what it shows, why it's right, and which systems it belongs to.

THE KEY IDEA

Rules that audit themselves

One declaration, four jobsEvery rule states what the call shows, point range, suit lengths, balanced or not, forcing status. That single declaration drives the bid itself, partner's inference, the explanation you're shown, and an automatic audit.
The auditAfter bidding a random deal, every call is checked against the hand that made it. A rule claiming 15-17 balanced on a 12-count with a singleton is caught mechanically rather than by someone reading the code.
It has caught real bugsAn early run flagged violations by the dozen, nearly all one class: rules testing support points while claiming high card points, so shapely hands made them lie. Each was either a wrong predicate or an over-broad claim.

VERIFICATION

How it's tested

Unit testsAssertions covering evaluation, situation classification, and the specific places the systems genuinely diverge, the 2/1 jump raise, the Standard American limit raise, the Precision one-club structure.
Property testsRandom deals are bid to completion in every system and checked for four properties: every call legal, every auction terminating, every rule's claim true of the hand that made it, and every position covered by some rule.
Deal auditEvery curated deal is replayed and the engine asked what it would bid at each turn. Disagreements are grouped by rule and by deal: many deals disagreeing with one rule means the rule is wrong; many calls wrong in one deal means the deal is.
What the audit has foundReal bugs, repeatedly. Bidding game on 16 opposite a raise that can be six points. Passing partner's responsive double. Reading partner's first action instead of their most recent. All three were found by the audit, not by inspection.

THE DIVISION

Where the AI actually sits

The engine decidesWhether your call was right, and what the right call is, comes entirely from the rule engine. The AI has no vote.
The AI explainsIt receives the hand, the auction, your call, the correct call, and the reasoning attached to the rule that produced it, then writes that as prose aimed at you. It is a translator, not a judge.
Why that splitLanguage models are excellent at explaining and unreliable at adjudicating. Splitting the roles means the thing that has to be right is deterministic, and the thing that has to be readable is the part models are actually good at.

HONESTLY

What it can't do yet

Coverage gapsA small share of positions have no matching rule. The engine passes and records the gap rather than guessing, and curated deals are checked to contain none, but a gap is a hand the system has no opinion about, which is worth knowing.
Interference over a strong 1♣Not modelled at all. It is the most-defended bid in bridge, so this is the Precision gap most likely to matter in real play.
Slam self-auditKeycard claims aren't machine-checked. The audit takes a hand with no trump suit, so keycard counts live in the explanation rather than in the checkable constraint.
Later competitive roundsA defender's third action is left unclassified. By then the auction is usually a high-level guess, and encoding guidance that doesn't exist would be worse than admitting the gap.
No double-dummy analysisThe engine judges bidding against system rules, not against what the cards can actually make. Contract outcomes aren't computed.

Every one of these is measured rather than estimated: the coverage figures come from the same property tests as the numbers above. A tool that told you it had no weaknesses would be telling you it hadn't looked.

See it work

The fastest way to judge any of this is to bid a hand and read what comes back.

Try a key bidRead the concepts