Hardware reconciliation

Reconciliation compares expected pieces from the game engine with actual observations from the board. It supports placement prompts and explains unexpected physical changes.

For example, the game may expect Player 1's road at Road 37 while the sensor reports an empty slot:

BoardMismatch {
  position: Road 37
  expected: Player 1 road
  actual: empty
}

This is a conceptual data contract. Field types, identifiers, and persistence are not finalized.

Observation	Useful response
Expected piece is missing	Ask the player to restore or complete placement
Wrong player's piece is present	Identify the global position and intended owner
Extra piece appears in an illegal location	Explain the mismatch without accepting the move
Settlement becomes a city	Compare with an authorized upgrade
Reading is unknown or hex offline	Explain sensing availability; do not claim the slot is empty

Debounce belongs in local sensing; reconciliation should consume stable observations. Multi-piece actions and the movement of the robber can temporarily produce intermediate layouts. Confirmation timing and grace periods are still to be designed.

Recovery should request a fresh physical snapshot and compare against the retained game state. A physical mismatch must not automatically debit resources, undo a legal action, or reveal private information. See events and game engine.