Mahjong Reference
Under the hood

Built so you can check the answer.

You should not have to trust a score just because software produced it. Follow the rules context, evidence and decisions behind a result.

  • Source-linked
  • Versioned
  • Tested
  • Type-checked
  • Build-verified
  • Explicit about uncertainty
Explore supported rules See the product walkthrough
The assurance chain

Rules → evidence → score → settlement → progression → record.

Trust depends on the whole chain. Each step has a defined job, and an unknown fact does not become a convenient assumption.

  1. 01

    Identify the rules

    Choose a named profile and version. Every result belongs to that rules context.

  2. 02

    Translate the source

    Source statements are reviewed into explicit requirements. Code alone does not prove a rule.

  3. 03

    Keep provenance attached

    Profile identity, version and evidence status travel with the saved game.

  4. 04

    Record table evidence

    Enter the hand and relevant table facts. Missing facts remain unknown.

  5. 05

    Score the hand

    The selected scoring grammar evaluates only the accepted evidence.

  6. 06

    Settle separately

    Payments are a profile-owned step that consumes the hand result.

  7. 07

    Progress separately

    Dealer, wind, round and game-end policy are resolved outside hand scoring.

  8. 08

    Keep one record

    The hand, settlement and progression form one saved game history.

Unknown means unknown.

Architecture under pressure

Reuse what is common. Keep differences explicit.

Eight published ruleset families were used as an external architecture stress test. They point to several scoring grammars, not one universal rule switchboard.

Read the stress test and its limits

This is pre-implementation architecture validation. It is not a claim that all eight families are implemented, source-certified or fully playable here. Production profiles still need their own appropriate source evidence.

  • European Classical
  • Hong Kong
  • Chinese Official (MCR)
  • Taiwanese
  • Riichi
  • Sanma
  • Zung Jung
  • American

Classical points × doubles

Classical and Western family

Pattern accumulator

Hong Kong, MCR, Taiwanese and Zung Jung

Riichi han + fu

Riichi and Sanma

Versioned target catalogue

American / NMJL-style cards

Evidence and verification

Show why something is known.

Different checks answer different questions. A passing build cannot verify a rulebook interpretation; a cited source does not show that the current code behaves as intended.

  1. 01

    Source review

    Rule claims are tied to identified sources and precise locations. The evidence ledger also records when a source is provisional or unresolved.

    View a source evidence ledger
  2. 02

    Human interpretation review

    A reviewer checks the source wording and locator, then keeps unsupported or ambiguous conclusions provisional or unresolved.

    See what human review establishes
  3. 03

    Behaviour checks

    Focused fixtures exercise concrete profile behaviour and edge cases. Passing tests show what the current code does; they do not establish what a source says.

    View the corpus closeout
  4. 04

    Architecture checks

    Paper manifests and stress tests ask whether materially different rule families can be represented without forcing them into one scoring model.

    View the paper manifests
  5. 05

    Comparator review

    Comparisons distinguish source-established rules from runtime similarity, provisional reuse and unknowns.

    View the comparator audit
  6. 06

    Release gates

    The repository defines automated test, TypeScript typecheck and production build commands. Run results belong to the exact revision checked.

    See the verification methods

Three layers, with different authority

Executable rules truth
What an exact profile and version currently instruct the scorer to do.
Evidence-backed facts
What identified sources and reviewed records support, including limits and unresolved questions.
Editorial explanation
Human-readable teaching that explains the facts but does not become a second rules database.
Read the reference architecture

What this does not claim

  • • No external certification or guarantee of perfect accuracy.
  • • Architecture coverage does not mean every family or variant is implemented.
  • • Matching runtime behaviour does not prove two sources say the same thing.
  • • Unknown or unresolved evidence stays visible as such.

A rule does not become true merely because it appears in the code.

Not “trust us”. Check us.

One recorded state. One story.

The reference layer is designed to be a view over structured, reviewed facts. Scores, settlements and game progress each keep their own rules while remaining connected in the saved record.

Open User Guide See product features