ChessZCam Beta: What It Can Do and Where Setup Conditions Matter
Computer vision can look magical in a controlled demonstration. A tournament hall is not controlled. Hands cross the board, light changes, pieces are bumped and phones heat up. This page explains the standard we want ChessZCam to meet—and the claims we will not make before the evidence is ready.
By zonChessPublished 2026-07-22Updated 2026-07-226–8 min read
Promise 01 · Describe the product accurately
ChessZCam is an assistive workflow, not an infallible witness
ChessZCam is designed to detect changes on a physical chessboard through an Android phone, maintain a digital position, record PGN and supply a browser overlay for OBS or vMix.
It should help reduce manual work. It should not be treated as the sole authority for an official result, an arbiter decision or a fair-play accusation.
Human responsibility remains
During beta, every important game record should be reviewed before publication or official use.
Promise 02 · Show the conditions
Good detection depends on a good view
Camera-based recognition is affected by the environment. We will document the setup conditions instead of hiding them outside the promotional video.
All squares must remain visible and the phone must stay stable.
Lighting should be even enough to distinguish pieces and square boundaries.
Hands, scoresheets, cups and other objects should not cover the board for long periods.
The device must have enough performance, battery and thermal headroom for the session.
Unusual sets, severe glare and visually similar pieces may require more testing.
Promise 03 · Make uncertainty visible
The software should ask for help instead of pretending
When several board changes are possible, the responsible behavior is to flag uncertainty, preserve the previous trusted position and let the operator review the moment.
Our design direction includes correction, undo, re-synchronization and operator notes because automation without recovery tools is not practical automation.
A system that admits “I am not sure” can be more trustworthy than one that is confidently wrong.
Promise 04 · Test outside the laboratory
Real venues will shape the product
Clean demo footage is useful for explaining an idea, but it is not enough to prove reliability. We need tests in different halls, lighting conditions, board styles, phone models, network setups and operator skill levels.
We will treat failures as product information: What blocked the board? How long did recovery take? Did the operator understand the warning? Was the saved PGN correct after review?
Promise 05 · Separate current capability from roadmap
A future idea is not a present feature
Current or testable
Features that exist in a build and can be demonstrated under stated conditions.
In development
Features being actively built but not yet reliable enough for normal use.
Exploring
Ideas that need research, design or user validation before commitment.
Not promised
Requests we may understand but cannot responsibly schedule or guarantee.
Product pages and release notes should use these labels consistently.
Promise 06 · Protect tournament integrity
ChessZCam does not replace the arbiter or event rules
Organizers decide where cameras may be placed, who can access a live position, whether a broadcast is delayed, and how player data is handled. ChessZCam must fit those rules.
The system should never be marketed as a shortcut around permission, privacy, fair play or official tournament procedures.
Promise 07 · Measure what matters
Accuracy alone is not the whole product
A useful beta should also measure:
how quickly a new user can calibrate the board;
how often the operator must intervene;
how long it takes to recover from an error;
whether the final PGN matches the verified game;
whether the setup survives a full round without overheating or disconnecting;
whether volunteers understand the warnings without developer assistance.
Promise 08 · Invite difficult feedback
The beta is for learning, not collecting compliments
We need testers who will describe the confusing setup step, the missed move, the phone that overheated and the warning they did not understand.
Positive feedback is encouraging. Specific failure reports are what help the product mature. Tell us what happened, what equipment you used and what you expected the app to do.
Join the conversation
What evidence would you need before trusting a camera-based chess record? Tell us the failure conditions and safeguards you believe matter most.